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Operating  System  Kernel 

Philip  Gary  Levy 

N Abstract 

Practical  aspects  of  the  design,  implementation,  and 
verification  of  operating  systems  are  explored  in  this 
thesis.  Axiomatic  techniques  for  proving  parallel  programs 
(developed  by  Hoare,  Owicki,  and  Gries)  are  extended  and 
applied  in  the  proof  of  an  operating  system  kernel.  The 
techniques  developed  apply  directly  only  to  environments 
with  a single  physical  processor. 

A technique  for  mutual  exclusion  that  is  simple  to  implement 
and  has  properties  that  contribute  to  verification  is 
presented.  It  is  based  on  the  disabling  of  context 
switching  to  allow  a single  process  to  execute  without 
pre-emption.  In  such  an  excluded  region,  sequential 
verification  techniques  can  be  applied. 

• The  axiomatic  specification  technique  is  extended  to  deal 

with  predicates  that  are  subject  to  interference.  An 
extended  axiom  consists  of-  two  parts:  one  that  specifies 
what  the  operation  actually  does  (using  any  predicates),  and 
the  other  that  uses  predicates  not  subject  to  interference 
and  hence  usable  in  proofs.  The  use  of  extended  axioms  in 


program  proofs  is  discussed. 

The  nature  of  predicates  and  deductions  used  in  program 
proofs  are  discussed.  In  some  contemporary  machines,  atomic 
access  to  variables  may  not  be  possible.  Several  conditions 
that  assure  safe  access  to  variables  are  presented.  The 
roles  of  mutual  exclusion,  priority-based  scheduling,  and 
point-of-view  in  establishing  freedom  from  interference  are 
explored. 

Finally,  the  specification  and  verification  of  the  kernel 
are  presented.  The  specification  technique  and  verification 
precedure  are  described. 


UNIVERSITY  OF  CALIFORNIA 
SANTA  CRUZ 


The  Design  and  Verification 
of  an  Operating  System  Kernel 

A Thesis  submitted  in  partial  satisfaction 
of  the  requirements  for  the  degree  of 

MASTER  OF  SCIENCE 

in 

INFORMATION  SCIENCE 
by 

Philip  Gary  Levy 
June  1979 


ii 


Acknowledgements 


I would  like  to  thank  the  following  individuals: 

Bill  McKeeman  for  his  hours  of  advice  and  criticism,  and 
innumerable  other  contributions; 

Loren  Meissner  for  helping  me  grow; 

David  Stonerod  for  starting  me  in  this  field;  and 

My  Parents  for  making  it  all  possible. 


! I ' 

„ This  research  was  partially  supported  by  Office  of  Naval 

Research  Contract  No.  N00014-76-C-0682 . 


I 


Table  of  Contents 


i 


The  Design  and  Verification  of  an  Operating  System  Kernel 

1.  Introduction 

1.1  Problem  Area 

1.2  Restrictions 

1.3  Work  Done  in  This  Thesis 

2.  Literature  Review 

2.1  Verification 

2.2  Parallel  Techniques 

2.3  Operating  System  Design 

2.4  Software  Engineering 

3.  On  Operating  System  Structuring  and  Verification 

3.1  Importance  of  Structure 

3.2  Virtual  Machines 

3.3  Levels  and  Families 

3.4  Data  Abstraction 

3.5  Binding  in  Programs  - A Measure  of  Connectivity 

3.6  Specification  of  Levels  and  Abstraction 

3.7  Use  of  the  Virtual  Machine  Model  to  Control 
Interference 

4.  Use  of  Context  Switch  Disabling  for  Primitive  Mutual 

Exclusion 

4.1  Interrupts  and  Context  Switch 

4.2  Practicality  Problems  and  a Solution 

5.  On  Problems  of  Axiomatic  Specifications  of  Parallel 

Programs 

5.1  Introduction 

5.2  Parallel  Programs  with  Shared  Variables 

5.3  Extended  Axioms 

5.4  Use  of  Extended  Axioms  in  Program  Proofs 


Table  of  Contents 


iv 


6.  On  the  Nature  and  Use  of  Predicates 

6.1  Introduction 

6.2  Assumptions  and  Restrictions  Concerning  Variable 
Access 

6.3  Interference 

6.4  Soundness  of  Basic  Computations 

6.5  Mutual  Exclusion  and  Its  Effect  on  Soundness 

6.6  Priority  Based  Scheduling  and  Its  Effects  on 
Soundness 

6.7  Local  Freedom  from  Interference 

7.  The  Design  of  the  Kernel 

7.1  Introduction 

7.2  The  Form  of  Specifications 

7.3  Kernel  Specifications 

7.3.1  Overview 

7.3.2  Abstract  Representation 

7.3.3  Virtual  Machines 

7.3.4  Operation  Axioms:  Global 

7.3.5  Operation  Axioms:  Local 

7.3.6  Invariants 

7.3.7  Theorems 

7.4  Discussion  of  Specifications 

8.  Proof  of  the  Kernel 

8.1  Introduction  and  Overview 

8.2  Consistency  of  Specifications 

8.3  PLZ/SYS  Semantics 

8.4  Concrete-Abstract  Map 

8.5  Consistency  of  Implementation  with  Specifications 

8.6  Verification  of  Theorems 

9.  Conclusion 

9.1  Review  of  Results 

9.2  Value  of  Verification  Analysis 

9.3  Difficulty  of  Specifications 

9.4  Further  Research 

10.  References  and  Bibliography 

* 


Introduction 


1-1 


1.1  - Problem  Area 

This  thesis  is  concerned  with  practical  aspects  of  the 
design,  implementation,  and  verification  of  operating 
systems.  Operating  systems  have  commonly  been  large  and 
complex  programs  that  were  plagued  with  bugs  and  were 
difficult  to  modify  and  maintain. 

Much  work  has  been  done  over  the  last  10  years  to  improve 
this  situation.  Programming  methodologies  have  been 
proposed  to  record  and  structure  the  design  of  operating 
systems.  Techniques  have  been  devised  and  developed  that 
allow  the  formal  proof  of  the  correctness  of  a piece  of 
program  text,  correctness  meaning  consistency  with  its 
specification. 

We  will  be  concerned  primarily  with  the  issue  of  correctness 
of  operating  systems.  Of  secondary  concern  are  engineering 
aspects  of  programs  (see  literature  review).  Most  of  the 
work  in  this  area  is  subjective  in  nature.  We  will  comment 
on  the  relation  of  some  of  these  techniques  to  the 
specification  and  verification  task.  ' 

With  the  growing  use  of  computers  in  sensitive  areas  such  as 
health  care  and  communications,  the  issue  of  the  production 
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of  programs  that  do  a "good"  job  has  received  much 
attention.  While  a precise  characterization  of  "good"  is 
beyond  the  scope  of  this  thesis,  we  can  give  some  properties 
that  a "good"  program  should  have.  The  program  should  be 
reliable  in  that  a user  should  be  able  to  predict  what  the 
program  will  do  given  a certain  request.  The  program  should 
be  characterized  by  and  behave  according  to  some 
specification  so  that  its  behavior  can  be  understood  without 
having  to  analyze  the  algorithms  themselves.  Also,  a program 
should  be  engineered  so  that  it  can  be  understood  and 
modified  without  violating  its  specification,  and  without 
excessive  effort. 

Correctness  of  a program,  then,  is  only  one  of  many 
properties  that  we  need.  A program  should  not  be  designed 
merely  to  simplify  the  verification  task;  this  may 
complicate  the  establishment  of  other  properties  of  the 
program.  * 

There  are  always  some  underlying  assumptions  about  the 
environment  in  which  a program  will  run.  A common 
assumption  is  the  reliability  and  correctness  of  the  machine 
on  which  the  program  executes.  While  failures  of  central 
processors  and  main  memory  systems  are  currently  fairly 
rare,  failures  of  mechanical  peripherals  are  more  frequent. 
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The  design  of  a program  can  greatly  affect  its  response  when 
some  assumption  about  its  enviroment  becomes  false. 
Correctness  alone  will  not  help  the  program  behave  in  such  a 
case  if,  as  is  typically  the  case,  error  situations  are 
omitted  from  the  specification  [Parnas  76a] . 


1.2  - Restrictions 

We  wish  to  deal  with  practical  aspects  of  the  verification 
of  a real  operating  system.  By  'real1  we  mean  one  that  has 
been  implemented  and  is  in  use  and  was  not  designed  with 
verification  in  mind.  The  system  was,  however,  designed 
with  "good"  software  engineering  practices  in  mind.  One 
would  expect  a system  to  be  designed  in  this  way  since 
verification  is  not  an  end  in  itself,  but  only  a useful 
(perhaps  very  valuable  and  useful)  property  of  a finished 
program.  Engineering  design  must  deal  in  a larger  scope 
which  includes  efficiency  or  performance  considerations, 
documentation,  maintenance,  modifications  (design  changes), 
and  completion  schedules. 

By  'practical',  we  mean  that  we  are  concerned  more  with  the 
analysis  of  predicates  and  variables  used  in  the  proof  of 
the  program  than  with  detailed  manipulations  of  the  actual 
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program  text.  Elimination  of  clerical  errors  in  the  final 
program  is  an  issue  not  addressed. 


We  will  consider  an  environment  that  has  a single  central 
processor.  Not  all  of  the  results  we  derive  will  be 
applicable  to  multi-processor  systems.  Nonetheless,  single 
processor  systems  represent  a significant  proportion  of 
operating  systems.  Network  systems  may  be  composed  of 
individual  single-processor  systems,  for  example.  Even 
though  there  are  multiple  processors  in  the  network  each 
individual  node  can  be  dealt  with  in  isolation  when  we  deal 
with  local  properties  of  the  system  on  that  node  alone. 

An  operating  system  kernel  for  nodes  on  a network  oriented 
system  was  implemented  in  early  1979.  This  system, 
hereafter  referred  to  as  the  Kernel,  is  implemented  on  a 
Z-80A  microprocessor  system.  The  system  is  written 
primarily  in  a high  level  language  (PLZ/SYS  [Snook  et  al 
78))  although  some  parts  are  in  assembly  language.  A 
subset  of  the  Kernel  is  specified  and  verified  in  this 
thesis. 
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1.3  - Work  Done  in  This  Thesis 

The  emphasis  of  this  thesis  is  the  verification  of  the 
Kernel.  Discussions  of  most  other  topics  are  related  to  the 
verification  issue. 

In  section  2,  literature  in  the  areas  of  program 
verification,  parallel  program  verification,  operating 
system  design,  and  software  engineering  is  reviewed. 

Section  3 covers  software  engineering  techniques  more 
thoroughly  and  relates  some  of  the  issues  to  verification. 
The  notion  of  binding  in  a program,  a measure  of  its 
interconnectivity,  is  related  to  the  difficulty  of 
verification  and  maintenance. 

The  achievement  of  mutual  exclusion  by  context  switch 
disabling  is  introduced  and  developed  in  section  4.  This 
technique,  when  applied  with  the  idea  of  virtual  machines, 
is  practical  and  very  simple  to  implement.  It  also 
contributes  to  the  verification  process  in  a positive  way. 

In  section  5,  problems  of  axiomatic  specification  of 
non-determinitsic  and  parallel  programs  are  explored. 
Variables  that  can  be  modified  by  interrupt  programs,  for 
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example,  are  difficult  to  use  in  specifications.  The  idea 
of  extended  axioms  is  introduce!  to  deal  with  this  problem. 
An  extended  axiom  consists  of  two  parts:  one  that  specifies 
what  the  operation  actually  does,  and  one  that  is  usable  as 
a proof  rule  in  the  usual  sense.  The  use  of  extended  axioms 
in  program  proofs  is  discussed.  This  approach  will  be 
needed  in  the  verification  of  the  Kernel. 

The  nature  of  predicates  and  deductions  used  in  program 
proofs  ia  explored  in  section  6.  An  assumption  that 
variables  can  be  accessed  in  an  atomic  manner  is  false  for 
many  computers.  Interference  between  parallel  programs  and 
its  effect  on  axiomatic  proofs  is  explored.  In  many  cases, 
interference  cannot  be  eliminated  and  techniques  for  dealing 
with  this  problem  are  developed.  These  techniques  involve 
the  use  of  mutual  exclusion  and  priority  based  scheduling. 

The  design  of  the  Kernel  is  presented  in  section  7.  The 
extended  axiomatic  approach  developed  in  section  5 is  used. 
Abstract  models  of  the  system  and  characterizations  of  the 
operations  are  developed. 

In  section  8,  the  proof  methodology  and  the  proof  itself  are 
presented.  First,  consistency  of  the  specifications  with 
some  global  properties  of  the  system  is  proved.  Then  a 
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mapping  from  the  abstract  model  to  the  concrete 
Implementation  is  presented.  Finally,  the  implementation  is 
shown  consistent  with  the  specifications  and  global 
properties  of  the  system  are  verified. 

In  the  conclusion,  section  9,  observations  about  the  entire 
thesis  are  presented  along  with  directions  for  further 


research . 
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2.1  - Verification 


Dljkatra  discusses  the  notions  of  program  correctness  end 
proofs  of  proqram  correctness  [Dljkatra  721 . He  eloquently 
argues  that  "the  art  of  programming  Is  the  art  of  organizing 
complexity"  and  that  some  formal  means  of  verifying  the 
programmer's  reasoning  Is  essential.  Here  he  gives  his 
famous  quotet  -'Program  testing  can  be  used  to  show  the 
presence  of  bugs,  but  never  to  show  their  absencel” 

Floyd  describes  the  state  of  a program  using  predicates 
relating  Its  variables  and  shows  how  predicates  are  affected 
as  flowchart  boxes  are  passed  [Floyd  67).  Loop  termination 
must  be  separately  argued,  typically  by  showing  that  some 
quantity  is  reduced  with  each  execution  of  a loop  and  this 
quantity  cannot  be  reduced  indefinitely. 

Hoare  expands  on  this  idea  and  introduces  the  formalism 
P{S1Q  to  indicate  that  if  a predicate  P is  true  before 
execution  of  program  statement  S,  then  a predicate  Q will  be 
true  when  S terminates  [Hoare  691.  The  formalism  can  be 
used  to  state  axioms  that  describe  the  semantics  of 
statements  in  a programming  language.  These  axioms,  when 
combined  with  appropriate  inference  rules  and  predicates 
defining  the  input  assumptions  form  a deductive  system  in 
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which  predicates  characterizing  output  variables  of  a 
program  can  be  proved.  Again,  termination  must  be  shown 
separately. 

The  axiomatic  approach  has  been  expanded  to  include 
procedures  and  parameter  passing  and  jumps  and  functions 
[Hoare  71a]  [Clint  & Hoare  72].  In  particular,  the 
programming  language  PASCAL  [Jensen  75]  has  been  axiomatized 
[Hoare  73]. 

A related  approach  to  semantics  and  verification  is 

Dijkstra's  weakest  pre-condition  (wp)  [Dijkstra  76].  Rather 
than  moving  forward  across  program  statements, 
vp(S,R) 

is  the  weakest  condition  required  to  guarantee  that 
predicate  R holds  after  execution  of  statement  S. 
Termination  of  S is  required.  A verification  that  predicate 
T holds  after  execution  of  program  P involves: 

1)  Computation  of  wp(P,T) 
and  verification  that 

2)  pre(P)  ->  wp ( P , T) 

where  pre(P)  is  a predicate  that  is  known  to  hold  before 
execution  of  P. 


Another  approach  to  program  verification  is  denotational 
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semantic*  [Scott  71].  Programs  are  considered  sets  of 
recursive  functions  whose  least  fixpoints  (in  the  lattice 
theory  sense)  define  the  meaning  of  the  program.  K more 
literal  modelling  of  environments  and  scopes  is  also  given. 

In  our  verification,  we  use  Hoare's  axiomatic  approach. 

2.2  - Parallel  Techniques 

Hoare's  axiomatic  approach  is  extended  by  Owicki  to  include 
parallel  programs  [Owicki  & Gries  76a,  76b].  Statements  SI, 
...,  Sn  are  executed  in  parallel  in  the  construct 
cobegin  SI  //  S2  //  ...  //  Sn  coend. 

Given  the  semantics  of  each  Si  in  isolation,  Pi  [Si]  Qi,  the 
axiom  describing  the  parallel  execution  of  SI  through  Sn  is 


Pi  [SI]  Ql,  ...»  Pn  [Sn]  Qn  are  interference  free 

Pi  6.. .&  Pn  {cobegin  SI  //  ...  //  Sn  coend}  Ql  &..  .6  Qn 

Interference  free  is  defined  by  (from  [Owicki  & Gries  76b] ) i 

Given  a proof  P{S}Q  and  a statement  T with  precondition 
pre(T),  we  say  that  T does  not  interfere  with  P{S]Q  if 
the  following  two  conditions  hold: 

1)  Q i pre(T)  [T } Q 


2)  For  every  statement  S'  within  S, 

pre(S')  (.  pre(T)  [T]  pre(S'). 
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It  aay  be  necessary  to  add  auxiliary  variables  to  a program 
to  construct  assertions  that  are  interference  free.  Owicki 
shows  that  such  variables  are  necessary  only  formally  and 
can  be  removed  from  the  program  without  altering  its 
meaning. 

Termination  of  parallel  programs  is  also  discussed.  In  the 
parallel  environment  it  is  necessary  to  show,  in  addition  to 
the  decrease  with  each  loop  execution  of  some  quantity  that 
cannot  infinitely  decrease,  that  other  proceses  increase  the 
quantity  only  finitely.  The  issue  of  deadlock  is  also 
discussed. 

Plon  presents  a methodology  for  the  design  and  verification 
of  operating  systems  [Flon  77].  Specification  techniques 
are  reviewed  and  the  specification  of  operating  systems  by 
use  of  an  abstract  representation  of  the  system  and  axioms 
for  operations  is  found  to  be  the  most  appropriate.  The 
axioms  are  stated  in  terms  of  the  abstract  representation. 
Invariant  predicates  describe  legal  states  of  the  abstract 
representation.  The  specifications  themselves  can  be  shown 
consistent  by  proving  that  the  invariant  predicates  are,  in 
I fact,  invariant  over  execution  of  each  operation. 

A mapping  from  the  concrete  to  the  abstract  representation 
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enables  verification  of  the  implementation.  A process 
scheduler  is  specified  and  verified  using  this  technique. 
It  is  assumed  to  be  run  in  a sequential  environment, 
however . 


Dijkstra's  weakest  pre-condition  semantics  is  extended  to 
the  parallel  environment  by  considering  all  possible 
interleaved  executions  of  all  processes.  This  combinatorial 
weakest  pre-condition  (cwp)  approach  is  claimed  impractical 
because  of  the  large  number  of  paths  of  execution  that  must 
be  considered. 


Plon  also  discusses  loop  termination  and  deadlock  and 
process  synchronization. 


We  use  Owicki's  application  of  axiomatics  to  parallel 
programs  and  Plon's  work  on  specifications. 


2.3  - Operating  System  Design 


Mutual  exclusion  plays  an  important  role  in  operating  system 
design.  Certain  computations  must  be  atomic  with  respect  to 
other  computations. 
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A monitor  [Hoare  74,  Br inch-Hansen  73]  provides  exclusion 
for  access  to  some  resource.  Monitors  for  arbitrary 
resources  or  groups  of  resources  can  be  defined.  The 
language  concurrent  PASCAL  includes  monitors  as  a built-in 
facility  (Br inch-Hansen  76]. 

The  idea  of  process  and  structuring  based  on  processes  is 
discussed  [Horning  & Randell  73].  Various  interactions  of 
processes  such  as  synchronization  and  communication  are 
discussed. 

Dijkstra  decomposes  a system  into  concurrent  processes 
[Dijkstra  68].  Semaphores  with  operations  P and  V are 
presented  as  a synchronization  mechanism. 

The  process  concept  and  several  forms  of  mutual  exclusion 
are  used  in  this  thesis. 

2.4  - Software  Engineering 

Several  design  techniques  have  been  suggested  with  the  goal 
of  producing  "good"  systems.  Although  many  of  the  concepts 
seen  intuitively  sound,  there  has  been  little  success  at 
measuring  the  effectiveness  of  the  techniques  in  a 
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qualitative  way.  An  empirical  approach  has  been  suggested 
but  its  application  is  difficult  due  to  the  many  variables 
and  effort  required  [Weissman  74], 

Wirth  describes  a stepwise  refinement  methodology  in  which, 
through  a series  of  similar  steps,  an  initial  general 
statement  of  a solution  is  refined  into  a final  program 
[Wirth  71],  The  various  steps  in  the  refinement  are 
transformations  of  the  previous  stage  and  represent  some 
group  of  design  decisions. 

Top-down  approaches  to  design  and  implementation  have  been 
discussed.  Denning  applies  the  term  "top-down"  to  a 
tree-like  development  of  all  aspects  of  program  development, 
including  design,  data  structure  definition,  and  code 
development  [Denning  74].  Morgan  applies  it  only  to  the 
design  process  [Morgan  77] , and  Myers  only  to  the  coding  and 
testing  process  [Myers  73]. 

The  concept  of  information  hiding  has  received  much 
attention.  Although  the  concept  is  very  general,  it  has 
been  applied  particularly  to  the  area  of  data  structures. 
The  notion  of  "abstract  data  types"  [Liskov  & Zilles  75]  has 
been  developed  and  appears  in  several  recent  programming 
languages  [DeRemer  & Levy  79],  Parnas  observes  that  module 
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interconnections  are  the  assumptions  that  they  make  about 
each  other  [Parnas  71],  He  notes  that  programmers  tend  to 
use  all  the  information  available  to  them  and  therefore 
information  about  modules  should  be  restricted.  The  issue 
that  management  should  control  how  information  is  restricted 
but  technical  people  should  control  what  information  is 
restricted  is  also  discussed. 

In  frequently  referenced  works,  Parnas  discusses  a 
data-oriented  decomposition  of  a problem  where  modules  are 
responsible  for  maintenance  of  a particular  data  structure 
[Parnas  72a,  Parnas  72c].  (A  KWICSORT  program  is  used  as  an 
example.)  The  specification  techniques  have  been  developed 
further  [Parnas  75d] . 

Dijkstra  begins  discussion  of  another  type  of  methodology 
based  on  a hierarchy  of  abstractions  [Dijkstra  68].  In  his 
development  of  the  "THE"  system,  various  layers  are  placed 
over  the  hardware,  each  defining  what  was  later  referred  to 
as  a "virtual  machine."  Some  abstractions  were  implemented 
as  processes.  A similar  design  methodology  is  expanded  to 
include  coding,  module  interconnection,  and  testing  [Liskov 
72].  The  term  "structured  programming"  is  restricted  to  the 
discussing  of  coding,  a distinction  frequently  missed  in 


other  works. 
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Parnas  [Parnas  76b]  discusses  the  effects  of  building  a 
virtual  machine  hierarchy  and  how  flexibility  and 
capabilities  can  be  lost  as  higher  abstractions  are  made. 
He  cautions  users  of  this  methodology  to  be  careful  not  to 
remove  a capability  that  eliminates  a useful  design  or 
feature.  Negative  aspects  of  top-down  design  procedures  and 
how  the  virtual  machine  approach  avoids  these  problems  are 
also  discussed. 

The  handling  of  unexpected  situations  plays  an  important 
role  in  the  reliability  of  a program  [Parnas  76a,  Parnas 
75b] . Inclusion  of  error  conditions  in  specifications  has 
been  advocated  [Parnas  75d,  76a].  The  term  "undesired 
event"  was  coined  to  replace  "error",  avoiding  the  complaint 
that  "errors  should  be  corrected,  not  handled"  [Parnas  76a]. 

"Levels"  in  the  hierarchy  need  not  necessarily  correspond  to 
abstractions  based  on  the  data  structures  within  an 
operating  system  [Parnas  76b,  Parnas  76c,  and  Habermann,  et 
al  76],  One  "level"  might  be  context  switching  based  on  a 
fixed  process  structure  and  a higher  level  might  include 
process  creation  and  deletion.  Thus,  the  "process 


management"  module  spans  levels  in  the  virtual  machine 
hierarchy.  This  allowed  interesting  and  useful  subsets  of 
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operating  systems  to  be  developed  as  a group. 

Although  the  engineering  aspects  of  the  Kernel  are  not 
specifically  discussed  in  this  thesis,  consideration  of  the 
techniques  above  played  an  important  role  in  its  design  and 
implementation . 
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This 

section 

discusses  software 

engineering  aspects 

of 

system 

design 

and  implementation. 

Also  discussed 

is 

the 

issue 

of  specification  of  operating 

system  programs 

and 

the 

relation  of  the  engineering  techniques  to  verification. 

3.1  - The  Importance  of  Structure 

Parnas  remarks  that  "structured  is  a euphemism  for 
' r estr icted ' " [Parnas  75b].  A structuring  technique 

eliminates  possible  organizations  by  providing  a framework 
in  which  the  problem  must  be  fit.  Structuring  is  important 
because  some  "frameworks"  have  valuable  properties.  These 
properties  facilitate,  for  example,  the  decomposition  of  a 
programming  task  allowing  many  people  to  work  simultaneously 
and  harmoniously  on  the  task.  Structuring  can  also  aid  the 
verification  task. 


In  this 

section, 

several 

str uctur i 

ng  techniques  are 

descr ibed 

briefly  and 

related 

to 

the 

verification  task. 

Positive 

engineer ing 

aspects 

of 

the 

techniques  are  also 

discussed 

. 
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3.2  - Virtual  Machines 

A machine  is  a facility  that  provides  capabilities  to  a 
program.  These  capabilities  include  data  storage  and 
manipulation.  Historically,  a machine  (in  the  context  of 
computers)  refered  to  a physical  object  that  could  execute 
instructions  and  store  data.  The  machine  need  not  be 
totally  implemented  in  hardware  and  the  term  virtual  machine 
was  applied  to  this  case. 

An  operating  system  provides  a virtual  machine  for  use  by 
user  programs.  The  instructions  available  include  some 
subset  of  the  instructions  defined  by  the  host  machine  and 
some  instructions  implemented  by  the  operating  system.  The 
operating  system  might  provide  more  than  one  kind  virtual 
machine.  Different  users  may  need  different  capabilities. 

An  operating  system  can  be  internally  structured  using  the 
notion  of  virtual  machines.  Starting  with  the  machine 
defined  by  the  host  machine,  some  new  facilities  can  be 
implemented  that  are  then  available  to  users  of  the  new 
"level"  and  at  the  same  time,  some  low-level  facilities  may 
be  removed.  The  new  facilities  are  new  instructions 
available  to  the  next  higher  level.  At  each  level,  new 
facilities  ate  provided  that  are  constructed  only  out  of  the 
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facilities  defined  by  the  next  lower  level  (lower  meaning 
closer  to  the  hardware) . 

In  this  manner,  the  system  is  constructed  based  first  on  the 
hardware.  The  next  level  is  the  hardware  supplemented  with 
a context  switch  "instruction".  At  increasingly  higher 
levels,  a simple  scheduler  might  be  added,  then  some  basic 
synchronization  mechanisms,  then  a clock  and  round-robin 
scheduler,  then  some  message  facility,  and  so  on.  Specific 
examples  of  decompositions  into  such  levels  appear  in  (Flon 
77],  [Saxena  76),  and  [Parnas  7 6d  1 . 

Note  that  the  implementation  of  these  levels  is  not 
specified.  Dijkstra  [Dijkstra  68]  structured  the  THE  system 
so  that  levels  were  implemented  by  processes.  This  need  not 
be  the  case,  however. 

A hierarchy  of  virtual  machines,  each  one  built  from  the 
level  one  lower  than  it,  is  thus  defined.  Each  of  these 
levels  can  be  independently  specified  and  verified.  This  is 
exactly  the  situation  when  the  semantics  of  a higher  level 
language  (such  as  PASCAL)  are  defined.  Programs  written  in 
the  language  are  based  on  the  operations  that  the  language 
provides  and  verified  in  terms  of  the  semantics  of  those 
operations,  independently  of  the  implementation  of  the 
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operations  provided  by  the  language. 

This  abstraction  greatly  simplifies  the  verification  task 
for  sequential  programs.  For  parallel  programs,  the 
decomposition  is  not  necessarily  as  clear  [Gries  76],  In 
the  case  of  a single  sequential  program,  there  is  no 
possibility  for  observation  of  the  internal  states  that  are 
part  of  the  implementation  of  a higher  level  operation. 
This  is  not  the  case  for  parallel  programs  where  one  program 
may  run  while  another  is  in  the  middle  of  executing  some 
operation.  Additional  analysis  is  required  to  deal  with 
this  situation.  The  subject  is  further  discussed  in  section 
6. 


3.3  - Program  Families  and  Subsets 

Consideration  of  the  order  in  which  design  decisions  are 
made  and  the  direction  in  which  the  virtual  machine  layers 
are  grown  leads  to  the  notion  of  a family  of  similar 
programs.  As  design  decisions  are  made,  the  system  becomes 
customized  toward  some  particular  goal.  From  a particular 
point  in  the  design,  a system  could  be  grown  in  many 
directions  and  the  closure  of  the  set  of  programs  so  grown 
constitutes  a family  that  share  common  ancestors. 
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A drawback  that  obsoletes  many  operating  systems  is  their 
lack  of  flexibility  in  terms  of  future  change.  Par-nas  gives 
an  eloquent  discussion  of  this  issue  [Parnas  77].  If 
thought  is  given  towards  developing  a family  of  programs 
during  the  entire  design  process,  then  future  changes  can  be 
made  more  managable.  Implications  of  design  decisions  can 
be  tracked  during  the  design  and  implementation  of  a system. 
Then,  if  that  decision  is  changed  as  the  goals  of  the  system 
change,  the  affected  areas  of  the  design  and  the 
implementation  can  be  identified. 

3.4  - Data  Abstraction 

The  notion  of  data  abstraction  has  emerged  as  one  of  the 
most  important  in  the  area  of  programming  [Liskov  72, 
Liskov&Z illes  75,  Parnas  72c] . Data  abstraction  is  an 
implementation  technique  where  implementation  decisions 
about  a data  type  are  hidden  from  the  users  of  that  type. 
Representations  can  be  changed  with  only  local  effects;  the 
programming  task  can  be  decomposed  along  abstraction  lines 
facilitating  work  on  a system  by  several  individuals. 


The  verification  task  can  be  broken  down  along  abstraction 
lines  similar  to  those  of  virtual  machines.  The  problem  of 
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parallel  programs  and  the  observation  of  internal  states  in 
the  implementation  of  an  abstraction  (which  are  hidden  from 
the  users  of  the  abstraction)  is  also  shared. 

3.5  - Binding  in  Programs 

Binding  refers  to  connections  between  pieces  of  a program. 
These  connections  can  be  direct:  access  to  variables  or 
calls  to  procedures  where  the  names  of  the  variables  or 
procedures  are  given,  or  indirect:  where  the  access  is 
through  a pointer  or  indirect  call  via  another  procedure 
that  has  direct  access. 

Binding  where  one  part  of  a program  refers  to  a specific 
name  from  another  part  can  be  dealt  with  by  conventional 
specification  and  verification  techniques.  Implicit  binding 
(for  example  assumptions  that  certain  variables  are  modified 
by  one  process  before  being  examined  by  another  process)  are 
not  specified,  cause  problems  in  implementation  and 
maintenance  and  are  difficult  to  indentify.  Implicit 
bindings  are  often  time  related  as  axiomatic  specifications 
deal  with  the  time  dimension  poorly. 


Binding  also  is  related  to  the  complexity  of  the 
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verification  task  as  it  is  an  indication  of  interconnections 
in  a system.  The  less  that  one  part  of  a system  can 
interfere  with  another,  the  less  that  need  be  considered  in 
the  verification.  If  two  subsets  of  a program  are  mutually 
independent,  then  they  can  not  interfere  with  each  other  and 
can  be  verified  independently. 

If  we  consider  the  boundaries  between  layers  in  the  virtual 
machine  hierarchy  as  horizontal,  data  abstraction  provides 
similar  boundaries  except  for  their  vertical  orientation. 
Data  abstractions  can  span  virtual  machine  levels  [Habermann 
et  al  76]  as  in,  for  example,  a Process  Control  Block 
abstraction  (see  figure).  Access  functions  to  hardware 
state  stored  in  the  control  block  would  appear  low  in  the  VM 
hierarchy  whereas  functions  for  creation  and  deletion  of 
Control  Blocks  would  likely  be  at  a higher  level.  Data 
abstractions  tend  to  reduce  the  binding  in  a system  and 
provide  a boundary  for  specification  and  isolation  of  the 
verification  of  the  abstraction  from  that  of  the  remainder 
of  the  system. 
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The  properties  and  operations  being  described  in  operating 
system  specifications  are  incomplete  in  that  they  are  in 
isolation  from  a program  that  uses  them,  anus,  for  example, 
we  cannot  show  that  the  operating  system  is  deadlock  free; 
that  is  a property  of  the  processes  which  run  on  it. 
Destructive  interference  between  user  processes  cannot 
necessarily  be  shown  either. 

The  majority  of  these  problems  are  in  area  of  termination 
(and  hence  deadlock  or  starvation).  If  our  system  has  a 
priority-based  scheduling  philosophy,  we  cannot  guarantee, 
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for  example,  that  a process  waiting  for  some  signal  will 
execute  if  that  signal  is  issued.  It  is  possible  that 
higher  priority  processes  will  run  indefinitely  so  we  can 
only  prove  that,  in  this  case,  the  process  waiting  for  the 
signal  will  be  eligible  to  run  if  the  signal  does  come. 

Several  specification  techniques  have  been  proposed 
[LiskovfcZilles  76).  Flon  analyzes  appropriateness  of 
several  of  these  techniques  and  concludes  that  the  use  of 
predicate  transformations  (based  on  axioms)  with  an  abstract 
representation  is  most  easily  applied  to  operating  systems 
(Flon  77).  Esssentially , an  abstract  representation  of  the 
system  data  is  defined  and  operations  are  specified  in  terms 
of  their  effect  on  this  abstract  representation. 

Paraphrasing  Flon,  the  axioms  characterizing  the  operations 
take  the  form: 

P(X)  { F (X)  } Q (X) 

with  the  usual  interpretation  of  such  an  axiom.  The 
predicates  are  parameterized  indicating  their  dependence  on 
the  abstract  representation,  X.  Given  a mapping 

A:Concrete  Representation  ->  Abstract  Representation, 
a verification  of  the  implementation  of  F would  involve  a 
derivation  of: 


P(A(x))  { implementation  of  F(A(x))  } Q ( A ( x ) ) 
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(where  x is  the  concrete  representation  such  that  A(x)*X). 
The  function  A must  be  well  defined  for  the  proof  to  be 
meaningful.  This  is  insured  by  establishing  invariants 
describing  allowed  configurations  of  the  abstract 
representation.  Given  such  an  invariant,  I,  we  must  also 
show  that  I is  in  fact  invariant  across  each  operation:  (for 
each  operation  F in  the  system) 

I(X)  and  P(X)  { F (X)  } I(X) 

This  can  be  done  in  terms  of  the  specifications  alone. 
Then,  any  implementation  that  satisfies  the  specification 
will  maintain  the  invariants. 

The  specifications  can  be  restated  in  terms  of  the  concrete 
representation  and  the  verification  performed  based  on  these 
specifications  as  well. 

We  must  be  careful  in  our  specifications  for  problems  that 
will  be  caused  by  the  parallelism  in  our  system.  As  a 
result,  for  free  variables  in  the  predicates  that  can  be 
affected  by  another  process,  we  must  use  extended  axiomatic 
specifications.  This  topic  is  discussed  in  section  5. 
Determination  of  what  variables  are  safely  used  in 
predicates  is  discussed  in  section  6. 


We  must  also  take  care  in  our  specifications  to  avoid 
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confusion  about  point  of  view.  An  axiom  of  the  form: 

Running (Q)  & P .pr ior i ty>Q. pr ior i ty  {WAKE  P}  Running(P) 
may  accurately  describe  a transition  in  the  state  of  the 
entire  system  when  a process  of  higher  priority  is  awoken, 
but  such  an  axiom  is  not  a valid  proof  rule  in  the  process 
Q.  In  fact,  from  the  point  of  view  of  Q,  the  specif icaition 
should  read: 

Running (Q)  and  ...  { WAKE  P } Running (Q) 

It  is  always  the  case  that,  from  a particular  process' 
reference  frame,  it  is  the  running  process.  In  the  case  of 
WAKE,  "after  execution  of  the  operation  { WAKE  P }"  means 
when  execution  of  Q continues. 

Thus,  two  sets  of  specifications  need  to  be  provided  for 
each  layer  in  the  virtual  machine:  one  specifying  the 
semantics  from  a global  view  that  accounts  for  all 
transitions  within  the  system,  and  one  that  provides  a user 
of  the  operations  provided  on  that  machine  with  the 
semantics  from  a local  view.  It  is  the  case  that  many 
operations  have  no  local  effect,  that  is  they  are  like  "no 
operation"  instructions  in  their  local  semantics.  The  WAKE 
operation  used  as  an  example  above  is  one  of  these;  there  is 
no  general  way  that  a process  can  detect  that  it  has 


executed  the  WAKE. 
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3.7  - Use  of  the  Virtual  Machine  Model  to  Control 
Interference 

The  virtual  machine  model  can  also  be  used  as  a tool  in 
limiting  the  capabilities  of  a process.  Each  process  runs 
on  some  specific  virtual  machine.  Each  virtual  machine  has 
an  instruction  set.  Processes  running  on  a virtual  machine 
having  no  instructions  that  affect  a particular  variable 
cannot  modify  that  variable.  This  technique  gives  a tool  in 
establishing  non-interference  among  a group  of  processes. 

An  example  relevant  to  the  operating  system  we  will  verify 
concerns  the  virtual  machine  that  normal  processes  run  on 
and  another  virtual  machine  that  interrupt  processing 
programs  run  on.  The  normal  processor  has  no  instructions 
that  affect  interrupt  priorities  or  control  flags;  the 
interrupt  processor  has  only  limited  capabilities  to  affect 
the  state  of  processes  running  on  the  normal  machine.  In 
particular,  interrupt  programs  can  wake  up  normal  processes 
but  may  not  affect  them  in  any  other  way. 
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In  this  section  we  describe  a low  level  mutual  exclusion 
technique.  The  technique  is  very  simple  and  easy  to 
implement.  Its  appl icabl i 1 ity  is  restricted  to  systems  with 
a single  physical  processor. 

Context  switching  is  the  reassignment  of  the  processor  from 
one  process  tc  another.  That  is,  the  hardware  context  is 
changed  to  run  another  process. 

4.1  - Interrupts  and  Context  Switch 

Most  programmers  who  have  dealt  with  real-time  systems  are 
familiar  with  the  technique  of  disabling  hardware  interrupts 
as  an  exclusion  mechanism.  Once  interrupts  are  disabled, 
only  voluntary  action  by  the  program  can  cause  a context 
switch.  If  the  program  takes  no  such  action,  mutual 
exclusion  is  guaranteed.  When  tne  interrupt  system  is  again 
enabled,  hardware  interrupts  can  cause  context  switching. 
This  is  the  essence  of  the  technique.  The  problems 
associated  with  the  missing  of  real-time  events  while 
interrupts  are  disabled  are  discussed  below. 

The  general  philosophy  of  this  procedure  is  different  from 
that  of  most  other  mutual  exclusion  techniques.  Whereas 
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most  exclusion  mechanisms  (such  as  semaphores  or  monitors) 
work  by  acquiring  permission  to  "go  ahead"  into  a critical 
region,  the  context  switch  control  works  by  stopping  all 
other  processes  from  doing  anything.  The  "wait  for 
permission"  techniques  require  some  form  of  queue  or  busy 
waiting  to  keep  track  of  processes  that  requested  but  were 
denied  permission  to  enter  a critical  region.  No  such 
additional  mechanisms  are  needed  with  context  switch 
control;  the  scheduler  already  keeps  track  of  those 
processes  not  running. 


Freedom  from  deadlock  caused  by  all  processes  becomming 
blocked  waiting  for  entry  into  an  excluded  region  can  be 
established  simply  by  showing  that  the  code  in  each  critical 
section  terminates  and  interrupts  are  enabled  on  exit. 
Furthermore,  since  all  other  parallel  activities  are 
suspended,  conventional  sequential  proof  techniques  may  be 
applied  to  a critical  section  when  exclusion  is  achieved  in 
this  way. 

We  have  not  solved  any  of  the  higher  level  resource 
allocation  deadlock  problems.  This  technique,  however,  can 
be  used  to  implement  more  complex  exclusion  mechanisms  such 
as  semaphores  or  monitors. 


r~ 

* 

Mutual  Exclusion  by  Context  Switch  Control  4-3 

4.2  - Practicality  Problems  and  a Solution 

The  question  of  practicality  must  still  be  addressed.  The 
disabling  of  the  hardware  interrupt  system  has  an 
undesirable  effect  on  real-time  responsiveness.  Use  of  the 
virtual  machine  approach  to  design  described  in  section  3 
helps.  We  can  achieve  a certain  amount  of  exclusion  by 
disabling  context  switching  of  processes  on  a particular 
virtual  machine  without  disturbing  the  interrupt 
responsiveness  of  the  system.  The  extent  of  the  exclusion 
achieved  is  reduced,  however. 

1 

Consider  the  case  of  two  virtual  processors,  the  I-machine 
and  P-machine.  The  I-machine  runs  only  interrupt  programs 
and  the  P-machine  runs  all  other  processes.  Scheduling  in 
the  I-machine  is  managed  predominantly  by  the  hardware  but 
the  interrupt  system  can  be  disabled  or  enabled.  Scheduling 
on  the  P-machine  is  performed  by  a scheduling  program  which 
runs  on  the  P-machine.  When  a P-machine  program  wishes 
exclusive  access  to  a facility  shared  only  among  P-machine 
processes,  it  need  only  disable  P-machine  context  switching 
to  achieve  it.  I-machine  programs  still  handle  hardware 
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interrupts  without  interference. 

If  a facility  is  shared  by  programs  on  both  the  P-  and 
I-machtnes,  then  context  switching  on  both  must  be  disabled 
to  achieve  exclusion.  In  the  case  a P-machine  process 
wishes  to  initiate  such  a critical  region,  the  P-machine 
context  switching  is  disabled  to  prevent  other  P-machine 
programs  from  interfering  and  the  I-machine  context 
switching  is  disabled  to  prevent  the  start  of  any  I-machine 
program.  In  practice,  the  size  of  regions  requiring 
exclusion  on  both  machines  is  sufficiently  small  (in  time) 
that  interrupt  responsiveness  is  not  impaired. 

Missing  real-time  events  is  the  main  problem  of  this 
technique.  Loss  of  such  events,  however,  is  not  increased 
when  the  virtual  processor  approach  is  used.  Time-critical 
events  are  handled  by  the  1-machine.  I-machine  programs  can 
queue  the  events  and  additional  processing  of  these  events 
can  be  done  on  the  P-machine  so  that  the  exclusion  does  not 
interfere  directly  with  the  processing  of  events.  In 
addition,  the  simplicity  of  the  technique  makes  more 
processor  time  available  overall  compared  to  other  exclusion 
techniques . 


I 
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5.1  - Introduction 

This  section  addresses  problems  of  writing  axiomatic 
specifications  for  procedures  that  execute  in  a parallel 
environment.  Conventional  axiomatic  specifications  have  a 
serious  deficiency  that  makes  some  supplement  necessary. 

Hoare  uses  the  notation 
P (0)  R 

to  specify  the  semantics  of  an  operation  Q,  namely,  that  if 
P is  true  before  the  execution  of  Q,  then  R is  true  after 
the  execution  of  Q [Hoare  69]. 

The  specifications  are  prototype  axioms  that  are  adaptable 
to  specific  statements  based  on  the  actual  content  of  the 
statement.  An  example  of  this  is  the  assignment  statement: 
e 

P { v : - e } P 
v 

The  left  predicate  is  derived  from  P replacing  free 
occurrences  of  v with  e.  A specific  case  of  the  use  of  this 
rule  is: 


x + l > 10  { x : * x+1  ) x > 10 
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An  operation  can  be 


Count  * 0 | 
These  two  axioms 
"Kick"  provided  that 
establ ished . 


specif 
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Such  a specification  serves  a triple  role.  First,  it 
provides  a specification  of  the  effect  of  the  operation 
"Kick"  without  constraining  its  implementation.  The 
specification  also  acts  as  a proof  rule  usable  in  a 
derivation  of  the  correctness  of  a program  that  uses  the 
"Kick"  operation.  Finally,  the  axioms  define  the  pre-  and 
post-conditions  needed  to  verify  the  correctness  of  the 
implementation  of  the  "Kick"  operation. 


5.2  - Parallel  Programs  with  Shared  Variables 

Such  specifications  are  unsound  when  the  context  is  expanded 
to  a parallel  program  environment.  Suppose  predicates  from 
the  axiomatic  specification  of  an  operation  are  used  in 
proofs  of  parallel  instruction  streams.  Variables  used  in 
these  predicates  might  be  changed  by  statements  in  other 


instruction  streams. 


It  is  no  longer  the  case 


that 
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predicates  describing 
as  assertions  about 
the  operation. 


the  effect  of  an  operation  can  be  used 
the  state  of  the  program  that  executed 


Consider  the  following  implementation  of  Kick: 

Kick  PROCEDURE 
entry 

if  Count<l  then  Count  :■  Count  + 1 fi 

end  Kick 

and  the  following  program.  The  statement 

cobegin  SI  //  S2  //  ...  //  Sn  coend 
indicates  parallel  execution  of  each  Si  [Owicki  & Gries 

76b].  Now  consider  a use  of  Kick: 

cobeg  in 

Count  :■  0 

Kick 

// 

repeat  case  RandomNumber ( 0 . . 1 ) 

<•3  : Count  :=  -1 

>*  .3  and  <.6:Count  :=  0 

>■  .6  : Count  :=  1 

forever 

co  end 

It  is  clear  that  the  two  processes  interfere  in  that  the 
shared  variable  Count  is  modified  by  both.  Let  us  suppose 
that  the  Kick  operation  is  not  inter ruptable.  We  are  left 
with  the  problem  that  even  though  the  axioms  above  describe 
correctly  the  effect  of  the  procedure  Kick,  they  cannot  be 
used  in  a proof  of  this  program  that  uses  Kick.  This  is  due 
to  the  possibility  that  immediately  after  execution  of  Kick, 


* 


I 


, < 
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the  second  process  changed  Count,  invalidating  the 
postcondition  of  the  Kick  operation.  For  the  same  reason, 
we  cannot  make  any  statement  about  the  precondition  for  the 
call  to  Kick. 

Any  value  of  Count  is  possible  before  or  after  Kick  is 
executed.  The  program  cannot  observe  the  actual  value  nor 
can  we  formally  predict  it. 

5.3  - Extended  Axioms 

We  are  left  with  the  problem  that  although  we  have  a set  of 
axioms  descriptive  of  the  action  taken  by  the  procedure 
Kick,  these  axioms  are  not  usable  as  proof  rules. 

A solution  to  this  problem  involves  the  separation  of 
predicates  in  the  axioms  into  two  groups.  One  contains 
axioms  characterizing  pre  and  post-conditions  that  are 
invariant  over  the  execution  of  the  system,  i.e.,  those  that 
cannot  be  affected  by  the  execution  of  other  processes.  The 
other  group  of  predicates  are  those  that  can  be  affected  by 
other  processes.  The  general  form  of  an  extended  axiom  is: 


f 
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P { operation  } Q 

with  oneof 

Pi  { operation  } Q1 
P2  { operation  } Q2 
• • • 

• • • 

The  interpretation  of  an  extended  axiom  is  as  follows. 

The  predicates  P and  Q must  not  be  affected  by  any  of  the 
operations  executable  by  other  concurrent  programs.  These 
predicates  are  useable  in  axiomatic  proofs  in  the  usual 
sense  [Owicki&Gr ies  76a,  76b]. 

Exactly  one  of  the  Pi  predicates  must  hold  at  any  time.  The 
action  characterized  by  the  oneof  axiom  whose  precondition 
holds  will  be  performed  by  the  operation.  Note  that  it  is 
not  generally  possible  to  determine  which  of  the  oneof 
axioms  applied  in  any  particular  execution  of  the  operation. 
Nor  is  it  possible  to  assert  the  truth  of  any  of  the  Qi 
post-conditions.  All  that  can  be  said  of  the  oneof  axioms 
is  that  the  action  specified  by  one  of  them  was  performed. 
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5.4  - Use  of  Extended  Axioms  in  Program  Proofs 


Let's  now  respecify  Kick  using  extended  axioms: 
-l<«Count<*l  { Kick  } -1 <=Count<=l 
with  oneof 


Count  * -i  {Kick}  Count  = 0 
Count  3 0 I Count  = 1 {Kick}  Count  * 1 


Again  considering 


co beg  in 


// 


Count  :=  0 
Kick 

if  Count  = -1  then  Print("At  least  one 

random  number  was  <.3")  fi 

repeat  case  RandomNumber ( 0 . . 1 ) 

<.3  : Count  :=  -1 

>=  .3  and  <.6:  Count  :=  0 

> = .6  : Count  :=  1 

forever 


coend 

we  can  now  prove  the  correctness  of  the  output  of  the  first 
program.  After  execution  of  Kick  we  have: 

-l<=Count<=l 

Since  Kick  was  executed,  one  of  the  actions  specified  by  the 
oneof  axioms  was  performed  so  that  at  some  point 
Count  = 0 | Count  = 1. 

The  precondition  for  the  execution  of  Count  :=  -1  (the  only 
statement  that  can  affect  the  predicate  Count=0  | Count*l) 
is  a random  number  <.3  and  this  is  the  only  assignment  that 
can  set  Count  to  -1.  Therefore  execution  of  the  Print 
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required  Count  « -1  which  required  an  random  number  < .3. 

Proofs  such  as  this  establish  global  properties  of  a system 
of  interacting  processes.  The  general  form  of  such  a proof 
involves  a case  by  case  examination  of  the  oneof  axioms  and 
then  consideration  of  preconditions  on  statements  of  other 
processes  that  can  affect  the  post-conditions  of  the  oneof 
axioms.  This  form  of  proof  is  used  to  establish  basic 
process  synchronization  properties  in  the  operating  system. 

An  important  aspect  of  the  application  of  the  use  of 
extended  axioms  involves  the  identification  of  statements 
that  can  affect  the  post-conditions  of  the  oneof  axioms. 
Techniques  for  identifying  such  statements  and  other  issues 
of  interference  between  processes  are  discussed  further  in 


section  6. 
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6.1  - Introduction 

This  section  explores  the  issue  of  the  use  of  predicates  to 
describe  program  state  in  parallel  programs.  Predicates  are 
assertions  about  program  variables  and  relations  between 
them. 

The  issue  of  access  to  variables  is  not  addressed  by 
axiomatic  proof  techniques.  Section  6.2  covers  this 
subject.  The  problem  of  shared  variables  has  been  discussed 
in  section  5 and  is  further  discussed  in  6.3.  Sections  6.4, 
6.5,  6.6,  and  6.7  propose  techniques  for  dealing  with 
interference. 


6.2  - Assumptions  and  Restictions  Concerning  Variable  Access 

We  define  a "safe"  access  to  a variable  as  one  that  loads  or 
stores  an  intact  value.  That  is,  there  is  no  possibility 
that  the  value  loaded  from  a variable  is  not  one  that  was 
previously  stored. 

The  following  are  sufficient  conditions  for  safe  access: 


The  Nature  and  Use  of  Predicates 


6-2 


1)  Access  to  the  variable  is  atomic.  This  is  a machine 
dependent  condition  as,  for  example,  there  is  atomic 
access  to  a 32-bit  variable  on  an  IBM  360  but  not  on 
a Z-80A.  Atomic  access  might  also  depend  on  the  form 
of  the  access.  Statically  allocated  16-bit  variables 
in  PLZ/SYS  are  accessed  atomically,  but  local 
variables  in  the  stack  frame  are  not. 


2)  Access  to  the  variable  appears  in  a region  of  the 
program  excluded  to  all  other  accessors  of  that 
var iable . 


3)  The  variable  is  local  to  a process.  In  this  case,  no 
other  processes  can  access  the  variable  at  all. 

4)  There  are  no  write  accesses  to  the  variable.  We 
assume  some  initialization  prior  to  the  environment 
where  there  are  multiple  accessors. 


5)  If  all  processes  that  read  and  write  the  variable  can 
be  identified,  then  some  statement  about  their 
behavior  might  be  made  that  would  allow  a conclusion 
that  an  access  to  a variable  is  safe. 
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6.3  - Interference 

Some  problems  with  the  use  of  predicates  as  assertions  about 
the  state  of  parallel  programs  were  discussed  in  section  5. 
The  general  problem  concerns  predicates  changing  from  true 
to  false  as  a result  of  the  action  of  concurrent  programs 
other  than  the  one  for  which  the  predicate  applies. 

This  problem  is  similar  in  nature  to  that  of  aliasing  in 
programming  language  semantics.  There,  a variable  can 
change  without  its  name  being  explicitly  mentioned.  The 
deductive  system  for  axiomatic  semantics  cannot  deal  with 
this  situation.  One  approach  is  to  eliminate  (forbid) 
interference.  This  is  analogous  to  the  approach  taken  in 
EUCLID  (London  et  al  77):  eliminate  aliasing.  This  won't 
work  for  operating  systems  because  some  interference  is 
necessary. 

Flon  notes  that  for  the  semantics  of  languages  for  parallel 
programs,  possible  pre-emption  points  must  be  identified 
[Flon  77],  For  example  the  statement 
x : = x + a 


The  Nature  and  Use  of  Predicates 


6-4 


must  be  decomposed  into  primitive  (and  atomic)  operations 
xO  :■  x;  xO  :*  xO  + a;  x :*  xO 

where  xO  is  a unique  temporary  (Flon  77,  page  54].  He  notes 
that  this  rather  unfortunately  ties  down  the  implementation 
of  such  an  operation,  even  on  a computer  that  has  an 
add-to-memory  instruction.  His  combinatorial  weakest 
precondition  (cwp)  semantics  for  parallel  programs  then 
considers  the  possible  interleaving  of  executions  of  the 
various  processes  so  that  modifications  of  x by  other 
processes  will  be  taken  into  account. 

The  combinatorial  weakest  precondition  was  found  unusable, 
even  in  optimized  form,  for  derivations  of  correctness  in 
the  Kernel.  The  cwp  semantics  operate  on  parallel  programs 
that  begin  and  end  nicely  (in  part  due  to  the  fact  that  wp 
semantics  is  used  to  show  termination  in  addition  to  partial 
correctness).  The  Kernel,  in  contrast,  is  only  a skeleton 
for  user  programs.  Much  of  the  code  is  invoked  by  user 
programs  and  we  wish  to  verify  the  Kernel  code  independently 
of  them.  We  need  some  more  powerful  way  to  deal  with  the 
problem  of  other  processes  changing  shared  variables. 
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6.4  - Soundness  and  Basic  Computations 

The  concept  of  logical  soundness  can  be  applied  to  axiomatic 
proofs.  A logical  system  is  sound  if  its  axioms  cannot  be 
used  to  derive  anything  that  isn't  "true".  An  axiomatic 
verification  of  a program  is  sound  if  it  does  not  make  a 
false  assertion  about  the  state  of  a program. 

The  scope  of  an  assertion  is  the  region  of  the  program  where 
that  assertion,  or  an  implication  of  that  assertion,  is 
assumed  to  hold.  It  is  necessary  to  show  that  an  assertion 
is  not  interfered  with  in  its  scope  [Owicki  & Gries  76a, 
76b]  . 

We  define  a "basic  computation"  as  a sequence  of 
instructions  in  which  there  is  no  voluntary  suspension  such 
as  a system  or  supervisor  call.  It  is  still  possible  for  a 
basic  computation  to  be  interrupted  and  execution  of 
concurrent  programs  to  be  interleaved  with  the  execution  of 
a basic  computation.  The  context  switch  that  causes  this 
must  be  based  on  events  not  controlled  by  the  instructions 
of  the  basic  computation. 

The  points  at  which  a process  voluntarily  relinquishes 
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control  of  the  processor  are  logical  points  at  which  to 
limit  the  scope  of  assertions  about  the  state  of  that 
process.  The  process  is  effectively  saying  "I'm  done  with 
my  sub-task.  It's  all  right  to  let  someone  else  go".  We 
will  examine  conditions  that  guarantee  soundness  of 
assertions  within  basic  computations. 

Soundness  of  the  deductive  system  in  a sequential 
environment  is  required  for  soundness  in  a parallel 
environment.  Sequential  soundness  is  assumed  in  the 
following  discussion. 

Freedom  from  interference  from  other  processes  is  a 
sufficient  condition  for  soundness.  Since  no  other 
processes  affect  any  of  the  predicates  within  the  proof  of  a 
basic  computation,  actions  performed  by  that  basic 
computation  can  be  proved  using  standard  sequential 
techniques . 

Other  conditions  that  imply  soundness  in  a basic  computation 
are  explored  in  the  next  three  sections. 
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6.5  - Mutual  Exclusion  and  Its  Effect  on  Soundness 


Various  forms  of  mutual  exclusion  can  guarantee  soundness 
within  a basic  computation.  If  all  context  switching  is 
disabled  then  no  interference  is  possible  and  sequential 
proof  techniques  are  sound.  The  exclusion  required  must 
exclude  processes  that  can  affect  variables  in  the 
predicates  that  appear  in  the  proof  of  the  basic  computation 
being  considered. 


There  is  an  interesting  relation  between  the  definition  of 
basic  computation  and  excluded  region.  When  exclusion  is 
released  (eg,  a V operation),  the  process  is  voluntarily 
allowing  itself  to  be  preempted  by  other  processes.  In  this 
case,  the  release  of  exclusion  is  the  instruction  that, 
delimits  the  basic  computation.  Thus,  the  excluded  region 
that  manages  a resource  is  a basic  computation. 

6.6  - Priority  Based  Scheduling  and  Its  Effect  on  Soundness 


A scheduling  philosophy  in  which  processes  are  assigned 
distinct  priorities  and  higher  priority  processes  are  always 
run  before  lower  priority  processes  provides  a useful  tool 
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for  establishing  soundness. 

Suppose  we  are  given  one  process  that  has  write  access  to  a 
variable  and  several  higher  priority  processes  that  have 
read  (but  not  write)  access.  Then  proofs  of  basic 
computations  of  the  higher  priority  processes  are  sound  with 
respect  to  the  variable  in  question.  This  follows  from  the 
scheduling  property  that  runs  the  reader  processes  until 
they  voluntarily  suspend  before  running  the  writer  process. 
Any  inspection  of  the  variable  and  action  based  on  its  value 
that  are  part  of  the  same  basic  computation  will  be 
completed  before  the  lower  priority  process  is  given  a 
chance  to  alter  the  variable. 

A voluntary  suspension  by  a reader  process  gives  the 
lower-priority  writer  a chance  to  alter  the  variable,  thus 
delimiting  the  basic  computation. 

Access  to  the  shared  variable  by  the  writer  and  readers  must 
be  shown  safe  as  part  of  a verification. 
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6.7  - Local  Freedom  from  Interference 

A weaker  condition  than  Owicki's  freedom  from  interference 
is  sufficient  to  insure  soundness. 

Consider  the  proof  of  a particular  process,  process  A. 
Statements  in  another  process  may  interfere  with  this  proof 
in  that  they  change  variables  that  falisify  assertions  in 
the  proof.  However,  if  these  changes  are  reversed  before 
process  A is  again  run,  the  changes  are  not  observable  in 
process  A and  do  not  interfere  with  its  correct  funtion. 

As  long  as  changes  to  variables  are  not  observable  by  a 
process,  then,  there  is  no  interference.  We  call  assertions 
that  are  subject  to  interference  that  is  always  removed 
before  it  becomes  observable  'locally  interference-free'. 
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7.1  - Introduction 

In  this  section  we  present  a specification  of  the  Kernel. 
First,  the  Kernel  is  discussed  informally.  The 
specification  technique  is  then  described.  Finally,  the 
specifications  are  presented  and  discussed. 

The  Kernel  is  designed  to  provide  a multiprogramming 
environment  for  microprocessor  systems.  The  Kernel  fulfills 
two  primary  functions:  providing  for  the  sharing  of  the  CPU 
by  "friendly”  programs,  and  providing  a standard  means  for 
communication  between  programs. 

The  hardware  consists  of  a Z-80A  microprocessor  [Zilog  77], 


main  memory. 

and 

various  peripheral  devices. 

The  Z 

-80A 

architecture 

provides  no  protection 

of  any 

kind; 

all 

instructions 

and 

the  entire  64K  byte 

address 

space 

are 

available  to  any  program.  A vectored  interrupt  facility 
handles  the  automatic  execution  of  I/O  interrupt  handlers  on 
a fixed  priority  basis. 

The  Kernel  is  not  responsible  for  I/O  and  interferes  with  it 
to  a minimal  extent.  User  programs  must  handle  all  I/O 
devices  even  if  interrupt  driven. 
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The  Kernel  manages  the  CPU  resource  only.  Higher  levels  in 
the  system  might  provide  memory  and  I/O  management.  Process 
are  run  based  on  the  scheduling  philosophy:  "run  the  highest 
priority,  ready  process".  Facilities  are  provided  so  that 
processes  can  block  or  awaken  each  other.  A process  is  not 
eligible  to  run  if  it  is  "blocked". 

Further  facilities  in  the  Kernel  provide  for  the  creation 
and  deletion  of  processes  and  for  the  alteration  of  process 
priority.  A clock  facility  and  round-robin  scheduler  share 
time  among  processes  of  equal  priority.  The  Kernel's 
hierarchical  structure  places  these  operations  at  different 
levels  and  the  Kernel  is  structured  so  that  all  these 
facilities  need  not  be  present. 

t 

A program  running  on  the  Z-80A  has  at  its  disposal  14  8-bit 
registers,  2 16-bit  index  registers,  a program  counter,  and 
a stack  pointer.  Pairs  of  8-bit  registers  can  be  used  for 
limited  16-bit  operations.  A stack  facility  is  provided 
that  allows  pushing  and  popping  of  16-bit  numbers  (from 
register  pairs)  and  automatic  stacking  of  procedure  call 
return  addresses.  The  interrupt  system  requires  that  the 
stack  pointer  always  point  to  a usable  stack  when  interrupts 
are  enabled  as  the  hardware  interrupt  sequence  involves 
pushing  context  information  on  the  stack. 


The  Design  of  the  Kernel 


7-3 


Due  to  the  intrinsic  lack  of  protection,  the  Kernel  makes  no 
attempt  to  restrict  access  to  any  of  its  system  calls.  User 
programs  are  required  to  behave  in  a friendly  way  and  not 
destructively  modify  programs  in  memory.  This  environement 
limits  the  reliability  of  the  system  in  that  damage  done  by 
malfunctioning  programs  cannot  be  contained. 

The  verification  of  a system  composed  of  user  programs  and 
the  Kernel  involves  verification  of  each  component  program 
and  verification  that  no  destructive  interference  exists. 
It  also  involves  the  establishment  of  non-overflow  of 
runtime  allocations  (such  as  the  procedure  call  stack  or 
dynamic  variables).  This  non-overflow  condition  is  an 
important  aspect  of  program  reliability  and  is  also  rarely 
formalized  in  the  language  semantics  in  which  programs  are 
verified. 

7.2  - The  Form  of  Specifications 

The  specif ication  of  the  Kernel  consists  of  the  following 
parts : 

1)  An  Abstract  Representation  [Flon  77].  This 
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representation  provides  a model  of  the  Kernel.  There 
is  a mapping  from  this  abstract  representation  to  the 
concrete  representation  (used  in  the  implementation). 
Any  state  that  the  Kernel  can  reach  can  be 
characterized  by  the  state  of  the  abstract 

representation.  The  specification  of  the  operations 
that  the  Kernel  provides  are  stated  in  terms  of  their 
effect  on  the  state. 

2)  A Set  of  Virtual  Machines.  Conceptually,  each  of  these 
machines  runs  concurrently  although  they  are  all 
implemented  on  a single  physical  processor.  Each 
machine  has  an  instruction  set  that  is  not  necessarily 
disjoint  from  other  machines.  There  may  be  some  rules 
about  relative  priority  of  the  various  machines. 

3)  Axioms  Describing  Each  Operation  from  a Global  Point  of 
View.  For  each  operation  on  each  machine,  we  state 
axiom(s)  that  describe  its  effect  on  the  abstract 
representation  of  the  Kernel.  These  axioms  are 
extended  as  discussed  in  section  5.  They  characterize 
transitions  in  the  Kernel  between  processes  and  are 
used  to  supply  verification  conditions  for  the  proof  of 
the  implementation  of  each  operation. 
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4)  Axioms  Describing  Each  Operation  from  a Local  Point  of 
View.  For  each  operation,  we  also  describe  its  effect 
from  the  point  of  view  of  a process  executing  the 
instruction.  ("Process"  is  defined  below.)  It  is 
these  semantics  that  are  needed  to  verify  a user 
program. 

5)  Invariants.  There  are  predicates  that  characterize  the 
legal  configurations  of  the  abstract  (and  concrete) 
representations.  Some  constraints  on  the  range  of 
certain  variables  in  the  abstract  representation  are 
implicitly  given  by  declarations  of  type  or  range  in 
the  specification  of  the  abstract  representation. 

6)  Theorems.  These  theorems  describe  global  properties  of 
the  system.  The  theorems  generally  deal  with  aspects 
of  interactions  among  processes  that  cannot  be  part  of 
the  axioms  describing  the  operations  themselves. 


The  specification  of  the  operations  use  the  extended 
axiomatic  technique  described  in  section  5.  Normally, 
axioms  are  of  the  form: 

P {S}  Q 


U 

I 

w 


i 
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which  reads,  "if  P is  true  before  execution  of  S,  then  Q 
will  be  true  after  execution  of  S has  completed."  To 
simplify  the  specification,  we  will  list  only  the  variables 
and  predicates  that  change  by  the  execution  of  S.  For 


example , 


is  equivalent  to  P { S } P 


for  all  predicates  P.  That  is,  S has  no  observable  effect, 
x “ v 1 {S}  x=v2 

indicates  that  only  the  variable  x changes  by  execution  of 
S.  Thus,  any  predicate  not  including  a free  occurence  of  x 
would  be  invariant  across  the  execution  of  S. 


7.3  - Kernel  Specifications 


7.3.1  - Overview 


Multiprogramming  in  the  Kernel  is  based  on  the  process  model 
[Horning  & Randell  73].  A process  is  informally  an  entity 
that  can  execute  instructions,  has  a name,  and  has  certain 
state  variables.  The  precise  definition  is  given  in  the 
next  section. 


Processes  execute  hardware  defined  instructions  or  Kernel 


defined  instructions.  We  may  consider  the  hardware 
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augumented  by  the  Kernel  as  a virtual  machine  with  an 
enhanced  instruction  set.  The  only  way  that  variables  in 
the  Kernel's  data  structures  can  be  accessed  is  by  the 
Kernel  defined  instructions. 

We  can  restrict  some  programs  by  allowing  them  to  use  only  a 
subset  of  the  instructions  defined  by  the  Kernel.  The 
Kernel  can,  thus,  provide  more  than  one  virtual  machine, 
each  with  different  characteristics,  on  which  user  programs 
may  run.  Specifically,  two  machines  are  so  provided:  the 
P-machine  and  the  I-machine. 

The  P-machine  provides  instructions  for  process 
synchronization  (BLOCK  and  WAKE) , instructions  for  P-machine 
context  switch  disabling  (FREEZE  and  THAW),  and  instructions 
for  controlling  the  interrupt  system  (El  and  DI) . Of  these, 
the  I-machine  shares  only  El  and  DI.  The  I-machine  also 
provides  an  instruction  to  wake  up  P-machine  processes 
( IWAKE) , and  instructions  to  terminate  interrupt  handler 
programs  (RETICS  and  RETI) . The  instructions  El,  DI,  and 
RETI  are  implemented  in  hardware  on  the  Z-80A.  The  P and 
I-machines  are  both  implemented  on  a single  Z-80A  processor. 

I-machine  programs  have  absolute  priority  over  P-machine 
programs  when  the  interrupt  system  is  enabled.  On  each 
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machine,  a priority  based  scheduling  philosophy  determins 
the  process  to  run.  The  scheduling  is  implemented  in 
hardware  on  the  I-machine  and  by  the  Kernel  on  the 
P-machine.  Context  switching  between  processes  can  be 
disabled  on  the  P-machine  by  using  the  FREEZE  instruction. 
Context  switching  on  the  I-machine  can  be  disabled  by  using 
the  D I (disable  interrupts)  instruction.  THAW  and  El  enable 
the  respective  switching  capabi 1 i t ies . If  the  P-machine 
executes  a DI,  context  switching  between  the  P and 
I-machines  is  disabled  so  that  the  P-machine  remains  in 
control . 

The  Kernel  maintains  state  variables  that  record  the 
condition  of  each  P-machine  process.  Both  P and  I-machine 
instructions  can  affect  these  state  variables.  The 
instructions  are  BLOCK,  WAKE,  and  I WAKE . 


7.3.2  - Abstract  Representation 

The  Kernel  abstract  representation  consists  of  the 
following : 

S The  set  of  P-machine  processes 

IS  The  set  of  I-machine  interrupt  handler  programs 

AM  The  active  virtual  machine  (oneof  ' P * or  'I') 

RPID  The  running  process  on  the  P-machine  (nil  if  none) 


T 
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IPID  The  running  program  on  the  I-machine  (nil  if  none) 

ION  Interrupt  system  enabled  (boolean) 

Freeze  P-machine  context  disable  call  count 

(non-negative  integer) 

RSCH  Run-the-scheduler  flag  (boolean) 

REDO  Scheduler-decision-questionable  flag  (boolean) 

The  model  of  a P-machine  process  is: 

Name  Type 

P.pri  0..255  (255  is  highest) 

P.st  oneof  (B,  R,  RW) 

P. state  machine  context 

The  model  of  an  I-machine  program  is: 

a name,  I 

a priority  I.pri 

a status  I. st 

an  event  I.ev 

a state  I. state 

7.3.3  - Virtual  Machines 

There  are  two  virtual  machines.  The  P-machine  runs  all 
processes  and  the  I-machine  runs  all  interrupt  programs. 

The  instruction  sets  of  the  P-  and  I-machines  are: 

P-Machine: 

{CS,  DI,  El,  FREEZE,  THAW,  BLOCK,  WAKE)  U IS  - {RETI , RETN} 
I-Machine: 

{ IWAKE , RETICS,  RESET,  DI , El,  RETI}  U IS 
where 


(some  ordered  set) 
oneof  (idle,  active) 
boolean 

machine  context 


Descr ipt ion 
a name,  P 
a priority 
a status 
a state 


IS  = all  Z-80A  instructions 
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One  component  still  needs  to  be  added:  the  process  by  which 
devices  request  interrupt  service  on  the  I-machine.  We  can 
consider  another  virtual  processor  to  represent  all  devices 
for  this  function.  It  has  an  instruction  INTR  I,  or 
"interrupt  request"  for  each  device  I.  The  specification 
for  these  instructions  are  given  in  figure  7.5. 


7.3.4  - Operation  Axioms:  Global 

The  axioms  that  describe  the  effect  of  the  execution  of  the 
instructions  on  the  P-machine  and  I-machine  are  listed  in 
figures  7.1  and  7.2.  They  are  discussed  in  section  7.4. 

7.3.5  - Operation  Axioms:  Local 

The  axioms  that  describe  the  effect  of  each  P and  I-machine 
instruction  from  the  point  of  view  of  a process  that 
executed  one  of  them  are  listed  in  figure  7.3  and  7.4. 

Note  that  it  is  always  true  that  the  running  process  is  the 
same.  Some  operations  have  no  observable  effect.  These 
actually  involve  global  properties  of  interactions  between 
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processes  and  their  effects  are  characterized  by  theorems. 


It  is  recommended  that  the  first-time  reader  skip  to  section 
7.4  and  read  it  while  refering  to  figures  7.1  - 7.5. 
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The  variables  P,  Q,  T range  over  S (P-machine  processes) 


and  I,  J, 

K range  over 

IS  (I-machine  programs) 

PI 

Freeze-0 

{ CS  > 

Pla 

with  oneof 

(cs) 

PSEL(RPID)  & ION  t.  ' RSCH  & 'REDO 

P2 

(Dll 

'ION 

P3 

(Ell 

with  oneof 

P3a 

ION 

(El) 

P3b 

"ION  & V J: 

~J . ev 

(El)  ION 

P3c 

'ION  & 

(El)  J. st-active  & IPID-J  6.  AM-  1 1 

J . ev  & 

(V  K : K . pr  i > J 

.pri  »> 

~K . ev) 

P4 

Freeze-k  & k<100 

(FREEZE)  Freeze-k+1 

P5 

P6 

Freeze-0 

Freeze-1 

(THAW) 

(THAW) 

Freeze-0 

P6a 

with  oneof 

(THAW) 

RPID-T  & PSEL(T)  & 

ION  & 

P7 

Freeze-k  & k>l 

(THAW) 

'RSCH  S,  'REDO 

Fr eeze-k-1 

P8 

QORPID 

(BLOCK 

Ql 

P8a 

with  oneof 

Q.st-B  | Q.st-R 

(BLOCK 

Q)  Q.st-B  & ION 

P8b 

Q.st-RW 

(BLOCK 

Ql  Q.st-R  {,  ION 

P9 

Q-RPID 

(BLOCK 

Q)  Freeze-0 

P9a 

with  oneof 

Q.St-B  | Q.st-R 

( BLOCK 

Ql  Q.st-B  (.  RPID-T 

& PSEL(T) 

P9b 

Q.st-RW 

(BLOCK 

'RSCH  & 'REDO  {, 
Ql  Q.st-R  & RPID-T 

ION 

& PSEL(T) 

RSCH  &,  'REDO  & 

ION 

P10 

Fr  eeze-0 

(WAKE  ( 

3) 

& 


& 


* 


PlOa 


with  oneof 

Q.st-R  | Q.st-RW  (WAKE  Q)  Q.St-RW  f.  RPID-T  h PSEl.(T)  t. 
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"RSCH  & 'REDO  & ION 

PlOb 

Q. st-B 

{WAKE  Ql 

Q.st-R  & RPID*T  S.  ' 
"RSCH  & ‘REDO  & ION 

PSEL(T)  & 

Pll 

FreezeOO 

{WAKE  Q} 

with  oneof 

Plla 

Q.st»R  | Q.st 

*RW  {WAKE  Q] 

Q . st*RW  6.  ION  & 
("RSCH  “>  ( RP I D=T  & 

PSEL(T) ) ) 

PI  lb 

Q. St-B 

{WAKE  Q} 

Q.  St=R  & ION  & 
("RSCH  =>  ( RP I D=T  & 

PSEL(T) ) ) 

The  predicate  PSEL(P)  is 

P.stOB  S.  V Q:  Q.pri>P.pri  =>  Q.st=B 


Figure  7-1.  The  P-machine  global  specifications 
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The 

variables  P,  Q, 

T range  over  S 

(P-machine  processes) 

and  I,  J, 

K range  over  IS 

(I-machine  programs) 

11 

Freeze=0  & 

{ IWAKE  Q} 

RPIDOnil  & 

Q.pr i >RPID . 

pri 

with  oneof 

i 

I la 

Q.st-R  1 Q. 

St“RW  (IWAKE  Q} 

Q.st=RW  & JO.ev 

I lb 

Q. st*B 

(IWAKE  Q ( 

Q.st=R  & JO.ev 

12 

Freeze=0  & 

(IWAKE  Q) 

RPIDOnil  & 

< 

Q.pr  iORPID 

.pr  i 

with  oneof 

I2a 

Q.st^R  | Q. 

St=RW  (IWAKE  Q} 

Q. st=RW 

1 2b 

Q. st=B 

(IWAKE  Q} 

Q. st=R 

13 

FreezeOO  & 

(IWAKE  Q] 

RSCH 

RPIDOnil 

; i 

with  oneof 

L d 

1 3a 

Q.  st=*R  | Q. 

St=RW  (IWAKE  Q) 

Q.  st  = RW 

I3b 

Q. st*B 

(IWAKE  Q] 

Q.  st  = R 

14 

RPID=nil 

(IWAKE  Q] 

( 

REDO 

with  oneof 

1 4a 

Q. st=R  | Q. 

St=RW  (IWAKE  Q} 

Q. St=RW 

I4b 

Q. st*B 

(IWAKE  Q] 

Q. st=R 

15 

IPID=J0 

{RETICS} 

with  oneof 

1 5a 

Freeze=0  & 

( RETICS ( 

IPlD=ni  1 & JO . st=  idle  s. 

(V  KOJO: 

AM= ' P ' & RPI D=T  & PSEL(T) 

K. st=idle) 

S,  'RSCH  & 'REDO  S.  ION 

16 

I*IPID 

{ RESET  1 

with  oneof 

I6a 

{RESET}  "I. 

ev 

17 

{DI}  ~ION 
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18 

with  oneof 

{El} 

I8a 

ION 

{El} 

I8b 

"ION  & ISEL(IPID)  {El} 

ION 

I8c 

"ION  & J.ev  & 

J . pr i>IPID. pr i & 

{El} 

IPID=J  & J 

(V  J:K.pr i>J.pr i 

= > 

"K.ev  ) 

19 

IPIDOJO 
with  oneof 

{ RETI } 

I9a 

ION  & I =1 PID 
(V  JOI: 

{ RETI } 

AM= ' P ' & I 

J. st=idle) 

I9b 

ION  & I =1 PID  & 
J.st=active  & 
JOI  & (V  KOJ: 

{RETI} 

I . st=idle 

K.pri>J.pri  => 

tn 

• 

W 

rf 

II 

idle  | K=I ) ) 

The  I-machine  scheduling  predicate 

I . st=acti ve 

& V J: 

J.pr i>I .pr i 

Figure  7.2.  I-machine  global  specifications. 
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Freeze*k  & k<100  {FREEZE} 


Fr eeze*0 
Freeze*! 


{THAW} 

{THAW} 


Freeze*k  & k>l  {THAW} 


QORPID 

Q=RPID 


{BLOCK  Q} 
{BLOCK  Q} 
{WAKE  Q} 


Fr eeze=k+l 


Freeze=0  & ION 
Fr eeze=k-l 


ION  & Freeze*0 


Figure  7.3.  Local  semantics  for  P-machine  operations. 


{ IWAKE  Q} 

IPID*J0  & ION  {RETICS} 
{RESET} 


false 


{ RETI } false 


Figure  7.4.  Local  semantics  for  I-machine  operations, 
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{ INTR  J} 

with  oneof 


ION  & AM-'P' 

{ INTR 

J) 

J.ev  & 
IPID-J 

"ION  & J. st*active  & 
& ISEL(J)  & AM-'I' 

ION  & AM-'I'  & 
J.pr i>IPID.PRI 

{INTR 

J} 

J.ev  & 
IPID-J 

"ION  & J. st-active  & 
& ISEL(J) 

ION  & AM-'I ' & 
J.pr i<-IPID.pr i 

(INTR 

J) 

J . ev 

"ION 

{INTR 

J) 

J.ev 

Figure  7.5.  Device  interrupt  request  specification 
The  variable  J ranges  over  IS  (I-machine  programs) 
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7.3.6  - Invariants 

The  invariants  characterize  legal  states  of  the  abstract 
representation.  We  can  embody  the  scheduling  philosophies 
of  the  P-  and  I-machines  in  this  way  by  making  invariant  the 
predicate  that  "the  highest  priority  ready  process"  is  the 
one  that  is  running  (except  under  certain  conditions). 

Invariants  for  the  P-machine  always  hold  from  the  point  of 
view  of  programs  that  execute  on  the  P-machine  (though  not 
necessarily  the  implementations  of  the  P-machine 
operations).  The  same  is  true  for  I-machine  invariants  and 
programs . 

P-machine  Invariants 

PIV1  (RPIDOnil  & Fr eeze=0)  =>  ('RSCH  & PSEL(RPID)) 

PIV2  (RPIDOnil  & 'RSCH)  =»>  PSEL(RPID) 

I-machine  Invar iant 

IIV1  ION  *>  (ISEL(IPID)  | IPID=nil) 

7.3.7  - Theorems 

These  theorems  describe  properties  that  cannot  be 
characterized  in  the  axioms.  They  involve  properties  of 
interactions  between  processes. 
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Theorem  L If  a BLOCK  P is  executed,  P will  not  run  until  a 
WAKE  P or  IWAKE  P is  executed. 

Theorem  2 . If  no  WAKE  P or  IWAKE  P operations  are  executed, 
a process  P will  not  run  after  at  most  2 BLOCK  P operations 
are  executed. 

Theorem  3 . A P-machine  context  switch  will  not  be  performed 
unless  Freeze=0  (ie,  no  context  switch  disable  exists). 


7.4  - Discussion  of  Specifications 


P-machine  Instructions 


In  this  section,  each  of  the  specifications  will  be  briefly 
discussed.  The  reader  is  refered  to  figures  7.1  - 7.4  for 
the  statement  of  the  axioms  describing  the  operations. 

The  context  switch  instruction  (CS)  is  described  in  axiom 
Pi.  Before  it  can  be  executed,  context  switching  on  the 
P-machine  must  be  enabled  (Freeze=0) . It  changes  the 


running  process  on  the  P-machine  to  the  highest  priority 
ready  process,  as  defined  by  the  scheduling  philosophy 
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predicate,  PSEL.  The  rerun  scheduler  flag  (RSCH)  and 
reconsider  scheduling  decision  flag  (REDO)  are  set  to  false, 
but  the  I-machine  can  affect  these  variables  so  that  their 
values  cannot  be  asserted  as  part  of  the  main  axiom. 

P2  and  P3,  P3a,  P3b,  and  P3c  characterize  the  hardware 
implemented  enable  and  disable  interrupt  instructions  (DI 
and  El).  The  interrupt-on  flag  (ION)  can  be  affected 
nondeterministicly  by  external  events  so  that  the  value  of 
ION  cannot  be  asserted  directly  in  P3.  When  interrupts  are 
disabled,  this  cannot  happen  so  that  an  assertion  of  “ION  is 
interference -free. 

FREEZE  and  THAW,  the  P-machine  context  switch  disable  and 
enable  instructions  are  characterized  in  axioms  P4  to  P7. 
FREEZES  can  be  nested  and  the  variable  Freeze  records  the 
nesting  level.  Note  that  the  maximum  nesting  level  is  100; 
the  action  taken  by  FREEZE  with  Freeze  greater  than  this  is 
left  undefined.  The  actions  of  THAW  when  Freeze^O  or 
Freeze>l  are  straightforward.  When  a THAW  causes  a 
transition  back  to  a state  where  context  switching  is 
enabled,  we  assert  that  the  highest  priority  ready  process 
will  begin  execution.  Again,  the  values  of  RPID,  RSCH,  and 
REDO  are  not  stable  so  that  values  of  these  variables  cannot 
be  predicted. 
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BLOCK  is  broken  into  two  cases.  In  one,  a process  other 
than  the  running  process  is  blocked.  There  is  no  transition 
in  the  system  in  this  case;  only  that  process'  state  is 
changed.  When  the  running  process  is  blocked,  any  FREEZE 
conditions  are  removed  and  the  next  process  to  run  is  chosen 
according  the  scheduling  philosophy.  In  each  case,  the 
actual  values  of  the  state  variables  of  the  process  that  is 
blocked  are  not  predictable  because  the  I-machine  may  affect 
them  at  any  time.  Some  transition  in  the  process'  state  is 
made  and  these  transitions  are  characterized  by  axioms  P8a, 

P8b,  P9a,  and  P9b. 

The  effect  of  WAKE  on  a process'  state  is  treated  similarly 
in  axioms  P10,  PlOb,  Plla,  and  Pllb.  During  a FREEZE,  no 
change  is  made  in  the  choice  of  running  process,  but  the 
variable  RSCH  records  the  possibility  that  the  running 
process  might  not  be  the  one  consistent  with  the  scheduling 
philosophy . 

I-Machine  Instructions 
——————  ———————— 

The  IWAKE  instruction  has  similar  effect  to  the  WAKE 
instruction  on  process  state,  but  in  the  case  of  a desired 
change  in  the  choice  of  running  process,  IWAKE  sets  JO.ev  so 

J 
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that  a special  interrupt  will  occur.  JO  is  an  interrupt 
program  that  has  the  lowest  priority  of  all  interrupt 
programs;  it  runs  only  when  there  is  no  other  interrupt 
processing  to  be  done.  As  it  is  an  I-machine  program,  it 
also  runs  before  the  P-machine  regains  control  of  the 
physical  processor.  JO  executes  the  RETICS  instruction  that 
then  forces  the  proper  transition  on  the  P-machine  so  that 
the  process  that  runs  will  be  the  highest  priority  ready 
process . 


If  I WAKE  is  executed  while  FreezeOO  (axiom  13),  it  sets 
RSCH  to  indicate  that  the  scheduler  should  be  run  when  a 
THAW  is  executed  with  Freeze=l.  It  is  also  possible  for  the 
IWAKE  to  be  issued  while  the  scheduler  is  running  (14).  In 
this  case,  IWAKE  sets  REDO  to  indicate  that  the  scheduler 
may  have  made  the  wrong  decision. 


The  RESET  instruction  (16)  clears  the  event  flag  for  the 
interrupt  program  that  executes  it.  Again,  the  flag  could 
be  set  at  any  time  so  that  ~I.ev  cannot  be  asserted  in 
general . 


17  and  18  describe  the  enable  and  disable  interrupt 
instructions  that  execute  on  the  I-machine.  These  are 


implemented  in  hardware  and  are  similar  in  semantics  to 
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their  P-machine  counterparts. 

RETI  (return  from  interrupt)  is  executed  when  an  interrupt 
program  has  concluded  the  processing  of  its  interrupt.  If 
there  are  no  other  interrupt  programs  in  the  active  state, 
control  returns  to  the  P-machine  (I9a).  Otherwise,  control 
goes  to  the  highest  priority  interrupt  program  that  is 
active  ( 1 9 b ) . 

Invar iants 


The  P-machine  invariant  PIVl  states  that  when  there  is  no 
rescheduling  freeze,  the  scheduling  philosophy  applies  and 
the  rerun  scheduler  flag  is  false.  The  factor  RPIDOnil 
extends  the  applicability  of  the  predicate  so  that  when  the 
I-machine  is  active,  the  predicate  will  hold  even  if 
RPID=nil . 

PIV2  characterizes  the  relation  of  RSCH  to  the  scheduling 
philosophy.  As  long  as  RSCH  is  false,  the  scheduling 
philosophy  is  in  effect.  When  RSCH  is  true,  the  scheduling 
philosophy  may  or  may  not  hold. 

The  I-machine  invariant  IIVl  characterizes  the  I-machine 
scheduling  philosophy.  When  interrupts  are  enabled,  either 
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the  highest  priority  active  interrupt  process  is  running,  or 
no  interrupt  process  is  running.  The  invariance  of  this 
relation  is  guaranteed  by  the  hardware. 
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8.1  - Introduction  and  Overview 


Several  steps  are  involved  in  verifying  the  Kernel.  Some 
steps  examine  properties  of  the  specifications  alone,  while 
others  deal  with  the  implementation  of  the  Kernel.  The 
predicates  used  in  the  proofs  also  need  to  be  examined  for 
safety  and  non-interference. 


The  Kernel 

is 

wr i tten 

mostly  in  PLZ/SYS  [S 

nook 

et  al , 

78] 

and  partly 

in 

assembly 

language  for  the 

Z-8 

OA. 

The 

algor i thms 

are 

all  expressed  in  PLZ/SYS  for 

the 

purpose 

of 

the  verification. 


Only  the  central  algorithms 
Code  that  checks  for  errors 
is  not  verified.  Nor  are 
errors  from  the  program. 


of  the  Kernel  are  examined, 
in  user  parameters,  for  example, 
we  seeking  to  eliminate  clerical 


The  proof  w 
predicates 
operations 
operation , 
that  given 
P { 


ill  proceed  as  follows.  F 
will  be  shown  to  be  invar 
(which  are  assumed  to  be 
op,  and  each  invariant  pred 
the  specification  for  op: 
op  } Q 


i 

i 

a 

i 


rst,  the  invariant 
ant  over  each  of  the 
tomic) . For  each 
cate  I,  we  must  show 
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we  have 

IiP->  9 k : P & V x (Q->I) 

where  x is  the  list  of  variables  free  in  P,  Q that  can  be 
different  in  Q than  in  P and  k is  the  list  of  variables  free 
in  P,  Q but  not  in  x [Flon  77).  Then,  any  implementation 
that  satisfies  the  specification  will  maintain  the 
invariants  [Flon  77).  The  verification  of  the 

implementation  must  establish  that  the  invariants  hold  at 
any  possible  pre-emption  points  within  op. 

For  example,  in 

Freeze-1  {THAW)  Freeze=0 
with  oneof 

{THAW)  RPID-T  & PSEL(T)  & 'RSCH  f.  'REDO 
x - Freeze,  RPID,  RSCH,  REDO 
k - (empty) 

The  simplified  form  of  the  invariant  rule  when  k is  empty  is 

I s.  P =>  V x (Q->I),  or  specifically, 

I & Freeze-0  «>  VFreeze,  VRPID,  VRSCH,VREDO 
((Freeze-0  & RPID-T  & PSEL(T)  & 'RSCH  & 'REDO)  *>  I) 

Second,  the  local  semantics  must  be  shown  to  be  consistent 

with  the  global  specifications.  If  local  and  global 

specifications  are  given: 


PI 

1 op  ) Q1 

(local ) 

Pg 

{ op  ) Qg 

(global ) 

then  we  must  show  that  no  path  of  execution  can  invalidate 
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the  implication: 

Qq  ->  Q1 

This  is  done  by  showing  that  Qg  is  invariant  across  all 
other  operations  or  by  giving  some  other  argument  that  the 
implication  holds. 

Next,  a mapping  from  the  abstract  representation  to  the 
concrete  implementation  is  established.  Access 
characteristics  of  the  implementation  variables  are 
examined.  Then,  the  code  itself  is  shown  to  be  consistent 
with  the  global  specifications.  This  establishes  the 
invariant  predicates  across  each  of  the  operations  and  the 
validity  of  the  local  specifications.  In  addition  to 
conventional  axiomatic  proofs,  arguments  are  presented  that 


access  to  variables  in  the  predicates 

and  consistent . 

in  the  proof 

s i s 

safe 

Finally,  the  theorems  are  proved. 

This  step 

once 

again 

involves  only  the  specifications.  The 

theorems 

will 

hold 

for  any  implementation  that  is 

speci f icat ions . 

consistent 

with 

the 
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2 - Consistency  of  Specifications 


We  wish  to  establish  three  properties  of  the  specifications: 
first,  that  the  predicates  PIV1,  PIV2,  and  IIV1  are 
invariant  across  each  of  the  operations  on  the  P and 
I -machines . This  aspect  of  the  verification  was  discussed 
in  section  3.6. 


Second,  we  must  show  that  the  post-conditions  used  in  the 
specifications  are  interference-free.  That  is,  the 
predicates  of  the  post-conditions  (other  than  the  oneof 
axioms)  must  be  invariant  over  operations  that  can  be 
executed  without  explicit  invocation  by  the  process  that 
executed  the  original  operation.  These  are  the  operations 
on  the  I-machine  (or  the  I-  and  P-machines  if  the  I-machine 
can  cause  a context  switch  on  the  P-machine). 

Third,  we  will  establish  that  the  local  semantics  are 
consistent  with  the  global  semantics.  It  must  be  the  case 
that  the  post-condition  in  the  local  specification  of  an 
operation  is  implied  by  the  post-condition  of  the  global 
specification,  and  that  this  implication  is  not  interfered 
with  by  any  of  the  other  operations.  If  the  operation 
results  in  a change  of  the  running  process,  then  the 
post-condition  in  the  local  specification  must  be  implied  by 
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the  post-conditions  of  whatever  operations  can  eventually 
cause  that  process  to  resume  execution. 


PIV1 

(RPIDOnil 

& Freeze 

=0)  =>  (~RSCH  & PSEL(RPID)) 

PIV2 

(RPIDOnil 

S.  ~RSCH) 

*>  PSEL(RPID) 

IIV1 

ION  =>  (ISEL(IPID) 

1 I PID=ni 1 ) 

PI Vl  is  invariant  on  the  P-machine. 


Axiom 

Post-cond i t ion 

Implies  PI VI 

PI 

PSEL(RPID) 

& ~RSCH  & 

Immed iate 

(1) 

(2) 

Fr eeze=0 

P2 

- 

No  effect 

on 

PIV1  (3 

P3 

- 

No  effect 

on 

PIV1 

P4 

Fr eeze=k+l 

& k + 100 

Immediate 

P5 

- 

No  e f f ect 

on 

PIV1 

P6 

Freeze=0  & 

RP I D=T  S,  PSEL(T) 

& 

Immed iate 

'RSCH 

P7 

Fr  eeze=k-l 

& k>l 

Immed  iate 

P8 

- 

No  effect 

on 

PIV1  (4 

P9 

Freeze=0  & 

RPI D=T  & PSEL(T) 

& 

I mmed iate 

'RSCH 

P10 

RPI D=T  & PSEL(T)  S, 

Immed iate 

Freeze=0  & 

'RSCH 

Pll 

FreezeOO 

Immediate 

11 

JO . ev 

Forces  execution  of 

RETICS 

(15)  (5) 

12 

Freeze=0  & 

RPIDOnil 

(6) 

13 

FreezeOO 

& RSCH 

Immed iate 

14 

RPID=ni 1 

Immed iate 

15 

RPI D=T  & PSEL(T)  & 

Immediate 

'RSCH  & Freeze=0 

16 

- 

No  effect 

on 

PIV1 

17 

- 

No  effect 

on 

PIV1 

18 

- 

No  effect 

on 

PIV1 

19 

- 

No  effect 

on 

PIV1 

Notes : 

(1) 

Immediate 

means  that  the  implication  follows 

by  only 

s impl i f icat ion . 

(2) 

RPIDOnil 

always  holds  for 

programs  running  on  the 

W 

l 


( 
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P-machine . 

(3)  No  effect  means  that  no  variables  in  the  predicate 
are  changed;  the  implication  follows  immediately. 

(4)  When  QORPID,  PSEL(RPID)  is  unaffected  by  a BLOCK  Q. 
The  other  variables  in  PIV1  are  unaffected  also. 

(5)  Before  control  returns  to  the  P-machine,  the  RETICS 
instruction  must  be  executed.  Its  effect  establishes 
the  invariant. 

(6)  When  Q. pr i<RPID. pr i , IWAKE  Q does  not  affect 
PSEL(RPID).  The  other  variables  in  the  invariant 
are  unaffected  also. 


PIV2  is  invariant  on  the  P-machine 


Axiom  Post-condition  Impl ies  PI V2 


PI 

PSEL(RPID)  & “RSCH 

Immediate 

P2 

- 

No  effect  on 

PIV2 

P3 

- 

No  effect  on 

PIV2 

P4 

- 

No  effect  on 

PIV2 

P5 

- 

No  effect  on 

PIV2 

P6 

RPID=T  & 

PSEL(T) 

& “RSCH 

Immediate 

P7 

- 

No  effect  on 

PIV2 

P8 

No  effect  on 

PIV2 

P9 

RPID=T  & 

PSEL(T) 

& "RSCH 

Immediate 

P10 

RPID=T  & 

PSEL(T) 

S,  “RSCH 

Immediate 

Pll 

“RSCH  => 

PSEL(RPID) 

Immediate 

11 

JO . ev 

Forces  execution  < 

RETICS  (15) 

(5 

12 

RPIDOnil 

(6) 

13 

RSCH 

Immediate 

14 

RPID=n i 1 

Immediate 

15 

RPID=T  & 

PSEL(T) 

& “RSCH 

Immediate 

16 

- 

No  effect  on 

PIV2 

17 

- 

No  effect  on 

PIV2 

18 

- 

No  effect  on 

PIV2 

19 

- 

No  effect  on 

PIV2 
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I 

I I VI  is  invariant  on  the  I-machine 


Axiom 

Post- 

condition 

Implies  IIV1 

11 

— 

No  effect  on  IIV1 

12 

- 

No  effect  on  IIV1 

13 

- 

No  effect  on  IIVl 

14 

- 

No  effect  on  IIVl 

15 

ION  & 

IPID=nil 

Immediate 

16 

- 

No  effect  on  IIVl 

17 

"ION 

Immediate 

18 

I8a 

_ 

Cases  I8a,  I8b,  II 
No  effect  on  IIVl 

I8b 

ION  & 

ISEL ( I P ID) 

Immediate 

1 8c 

"ION 

Immediate 

19 

1 9a 

ION  & 

I PID=n i 1 

Cases  I9a  and  I9b 
Immed iate 

1 9b 

ION  & 

I PID=J  & ISEL(J) 

Immed iate 

The  predicates  that  appear  as  post-conditions  in  the 
specifications  are: 


Predicate  Axiom (s) 

"ION  P2,  17 

Freeze*k  & k<>0  P4,  P7 

Freeze=0  P6,  P9 

JO . ev  II 

RSCH  13 

REDO  14 


Operations  on  the  I-machine  can  change  only  the  following 
variables  in  the  indicated  manner. 


r 

n 

ii 


i : 
i l 


j 


i 
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Variable 

Change 

RSCH 

Set 

to 

tr  ue 

(except 

REDO 

Set 

to 

true 

(except 

ION 

any 

I . ev 

for 

any 

I 

any 

I. St 

for 

any 

I 

any 

P.  St 

for 

any 

P 

Set 

to 

R or 

RW 

IPID 

any 

RPID 

any 

AM 

any 

P-machine  predicates 


Non-interference  with  the  P-machine  predicates  (ION,  'ION, 
Freeze=k)  is  established  in  section  8.5 


I -machine  predicates 


RSCH  and  REDO  can  only  by  set  on  the  I-machine.  They  are 
only  reset  when  the  P-machine  again  runs,  the  I-machine 
program  having  terminated. 

Local  Specifications 

From  the  point  of  view  of  the  P-machine,  ION  is  invariant 
over  all  I-machine  operations.  Reason:  if  ION=false  the 


!' 


I-machine  cannot  run  so  that  ION  is  invariant.  If  ION=true 
then  the  I-machine  can  run,  but  the  only  transitions 
returning  control  to  the  P-machine  (15,  19)  assert  ION  as 
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post -condi t iorts . 


Global 

Local 

Required 

Axiom 

Axiom 

Post-cond i t ion 

Impl icat ion 

FT- 

rr 

. . & ION  & . . 

Immediate 

P2 

L2 

"ION 

Immediate 

P3 

L3 

ION  | ION  | AM= ' I 

' & ..  (1) 

P4 

L4 

Fr eeze=k+l 

Immediate 

P5 

L5 

Fr  eeze  = 0 

Immediate 

P6 

L6 

Freezea0  & ION 

Immediate 

P7 

L7 

Fr eeze*k-l 

Immediate 

P8 

L8 

. . & ION  & . . 

Immediate 

P9 

L9 

Freeze=0  & ION 

Immed i ate 

P10 

LI  0 

. . & ION  & . . 

Immed  iate 

Pll 

LI  0 

. . & I ON  & . . 

Immediate 

11-14 

I LI 

Immediate 

15 

IL2 

AM= 1 P ' 

I-program  terminates 

16 

IL3 

Immediate 

17 

IL5 

"ION 

Immediate 

18 

IL4 

ION  I ... 

(2) 

19 

IL5 

AM= 1 P ' 

I-program  terminates 

(1) 

In  case 

P3c,  the  argument 

above  shows  that  ION  must 

hold  when  control  finally 

returns  to  the  P-machine. 

(2) 

In  case 

I8c,  control  can 

only  return  to  the 

interrupted  process  by  19  which  has  post-condition 
ION. 
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8.4  - Abstract-Concrete  Map 

The  Abstract-Concrete  map  relates  each  variable  in  the 
abstract  representation  to  a variable  in  the  concrete 
representation.  Refer  to  section  7.3.2  for  a discusstion  of 
each  element  of  the  abstract  representation. 


Abstract 

Concrete 

RPID 

RPID  if  SCHR=  false 
nil  if  SCHR=true 

I PID 

implicit 

Freeze 

Freeze 

ION 

IFF 

RSCH 

RSCH 

REDO 

REDO 

P.pr  i 

P.  pr  i 

P.  st 

P.BW  and  P.WW 
(boolean) 

P. state 

hardware  registers 

I .pr  i 

I. st 

bus  wiring 
implicit 

I . state 

I . ev 

hardware  registers 
hardware 

AM 

implicit 

S 

PI  ist 

IS 

hardware 

Comments 
4 bytes 

implicit  in  hardware 
1 byte 

a hardware  register 

1 byte 
1 byte 

1 byte  ( 0 . .255) 
with  the  encoding: 

P.BW  & 'P.WW  <=>  P . st=B 
~P . BW  & ~P.WW  <=>  P . St=R 
~P . BW  & P.WW  < = > P . S t = RW 
(P.BW  & P.WW  is  an 

impossible  state) 


hardware  determined 

based  on  activation  history 

which  is  hardware  managed 


hardware  managed 

Plist  is  a list  ordered 
by  priority. 

predetermined  by  system  wiring 


Figure 
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8.1.  Concrete-Abstract  map 


Abs4r«cV 


Co»»ci  e 4c. 
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8.5  - Verification 

Each  of  the  operations  must  be  verified  to  be  consistent 
with  the  specifications.  The  predicates  in  the 

specifications  are  restated  in  terms  of  the  concrete 
representation. 

Only  the  instructions  implemented  in  the  Kernel  software  are 
verified.  The  instructions  El,  DI , RETI,  RESET,  and  INTR 
are  implemented  by  the  Z-80A  hardware. 

Each  proof  consists  of  two  parts.  First,  the  axiomatic 
derivation  of  the  properties  of  the  program  text  being 
examined  is  given.  Then,  arguments  establishing  safety  and 
non-interference  of  each  variable  access  and  predicate  are 
given . 

Pr el iminary  Discussion  of  Intef erence 

Some  preliminary  analysis  of  the  specifications  will 
simplify  the  non-interference  arguments. 

Pre-conditions  for  an  involuntary  context  switch  are: 
RPIDOnil  & Freeze=0 

When  these  preconditions  do  not  hold,  the  only  variables 
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subject  to  interference  are: 
Variable 

P.st  (P.WW,  P.BW) 

RSCH 

REDO 

I . ev 

I . st 

IPID 


Axiom  Comments 

11-14  for  any  P in  S 

13 

14 

16  and  INTR  for  any  IOJO 

18,  19,  and  INTR 
18,  19,  and  INTR 


Any  predicates  not  involving  these  predicates  are 
interference-free. 


Freeze=0  is  not  subject  to  interference.  Reason:  No 
I-machine  operations  can  modify  Freeze.  If  it  is  modified 
by  the  P-machine,  it  must  be  changed  back  to  0 before  a 
context  switch  (CS)  can  cause  the  process  that  expected 
Freeze=0  to  resume. 


FreezeOO  is  not  subject  to  interference.  Reason:  No 
I-machine  operations  can  modity  Freeze.  Because  FreezeOO, 
no  context  switch  can  occur  on  the  P-machine  so  that  no 
operations  that  might  modify  Freeze  can  be  executed. 


ION  is  not  subject  to  interference.  Reason:  ION=true  is 
always  restored  by  the  I-machine  before  returning  to  an 
interrupted  I-  or  P-machine  process.  If  ION  is  modified  by 
the  P-machine,  it  is  restored  to  ION=true  as  part  of  a 
context  switch  (CS)  that  resumes  a process  that  had  ION=true 
initially. 


6s  (VI 
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“ION  is  not  subject  to  interference.  Reason:  No  I-machine 
programs  can  run  so  that  no  operations  that  can  affect  ION 
can  be  executed  by  other  than  the  running  process. 
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FREEZE 


THAW 


Figure  8-2.  Algorithms  for  the  Kernel 
in  terms  of  concrete  representation. 


Freeze  :*  Freeze+1 


if  Freeze>0  then  Freeze  Freeze-1; 

if  Freeze=0  and  RSCH*true  then  CS  fi 
fi 

Local  Variable:  Best 

Save (RPID. state) 

SCHR  true;  RPID  :*  nil 
do 

SCHR  true;  REDO  :=  false 
Best  :*  Plist 


if  Best=nil  then  exit  fi 
if  Best .BW=f alse  then  exit  fi 
Best  :*  Best. link 


if  REDO=true  or  Best^nil  then  El;  repeat 

else  exit 
fi 


RPID  :=•  Best;  SCHR  :=*  false;  RSCH  false 
El 

Load (RPID. state) 


WAKE  (P) 


FREEZE;  DI 

if  P.BW*true  then  P.BW  :*  false 

else  if  P.WW*false  then  P.WW  :=  true  fi 

fi 


if  P.pr i>RPID.pr i then  PSCH  true  fi 
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Specification 


Freeze-0 


with  oneof 


{CS}  ION 


(CS>  PSEL(RPID)  i -RSCH  t>  "REDO 


The  predicate  PSEL(P)  restated  in  terms  of  the  concrete 
representation  is: 

PSEL(P) : -P.BW  & V R:  R.pri>P.pri  ->  R.BW 
Process  list  property: 

POnil  & P.linkonil  ->  P.pri>P.link.pri 


Proof 


1  {Freeze-0} 


Save(P.8tate) 

2 {Preeze-0} 

SCHR  :-  true;  RPID  :-  nil 

3 {Freeze-0  6 SCHR  6 RPID-nil  } 


4 {Freeze-0  6 SCHR} 

SCHR  :-  true;  REDO  :-  false 
Best  :-  Plist 

5 {Freeze-0  fc 
SCHR  fc 

{ (REDO  | (BestOnil  & V R:  R.pr i>Best.pr i ->  R.BW)) 
I (REDO  I (Best-nil  & V R:  R.BW))]  } 


6  {Freeze-0  & 

SCHR  4 

( (REDO  | (BestOnil  & V R:  R.pr  i>Best  .pr  i ->  R.BW)) 
I (REDO  | (Best-nil  t V R:  R.BW))]  } 
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if  Best-nil  then 


7 (Freeze-0  & 

SCHR  & 

(REDO  ( (Best-nil  t V R:  R.BW))  } 

exit  fi 


8 (Preeze-0  & 

SCHR  fc 

(REDO  | (BestOnil  t V R:  R.pr i>Best.pri  ->  R.BW))  } 
if  Best .BW-f alse  then 


9 (Freeze-0  & 

SCHR  fc 

(REDO  | (BestOnil  & V R:  R. pr i>Best . pr i ->  R.BW))  fc 
"Best.BW  } 

exit  fi 


10  (Preeze-0  6 
SCHR  & 

( (REDO!  (Best.linkOnil  fc  V R:  R.pr  i>Best.l  ink. pri  -> 
(REDOI (Beet. link-nil  & V R:R.BW))  )} 

Best  :-  Best. link 


11  (Preeze-0  & 

SCHR  fc 

((REDO  | (BestOnil  6 V R: 
(REDO  | (Best-nil  & V R: 

OD 


R.pr i>Best. pri  ->  R.BW))  I 
R.BW))  ] } 


12  (Preeze-0  & 

SCHR  & 

[(REDO  | (Best-nil  & V R:R.BW  ))  | 
(REDO  I (BestOnil  & PSEL(Best)  ) ) ] } 

DI 

13  (Freeze-0  & 

SCHR  fc 

[(REDO  | (Best-nil  & V R:R.BW  ))  | 
(REDO  | (BestOnil  & PSEL ( Best)  ) ) 1 & 
"ION  } 


if  REDO-true  or  Best-nil  then 


• BW))  | 


14  (Preeze-0  & 
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SCHR  k 
"ION  } 

El 

15  {Freeze-0  k 
SCHR  k 

ION  } 

repeat 

else 

16  { Freeze-0  & SCHR  k "REDO  & BestOnil  & PSEL ( Best)  k “ION  } 


17  {false} 

OD 

18  {Freeze-0  k SCHR  k "REDO  k BestOnil  k PSEL  (Best)  k "ION  } 

RPID  Best 

SCHR  False 

19  {Freeze-0  k "SCHR  k "REDO  & RPIDOnil  k PSEL(RPID)  k "ION  } 

El 

20  {Freeze-0  k ION} 

Load (RPID. state) 

21  {Freeze-0  k ION} 


Comments 

We  must  establish  non-interference  for  each  predicate  and 
safe  access  for  each  variable. 

Predicates  3,  4,  14,  15,  and  17  are  interference-free  as 
they  involve  no  variables  that  the  I-machine  can  modify  and 
the  P-machine  cannot  context  switch  because  SCHR-true. 

In  predicates  5-13,  the  variables  Freeze,  SCHR,  and  ION  are 
not  subject  to  interference.  The  clause  (REDO  I ...)  is 
also  interference-free  because  the  I-machine  can  only  set 
REDO-true  thus  making  the  clause  true.  It  does  this  exactly 
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when  variables  P.st  are  modified  (14).  Thus,  if  there  is 
interference  with  P.st,  REDO  is  set  to  true  insuring  that 
the  clause  remains  true. 

Predicates  16,  18,  and  19  are  interference-free  as  they 
include  “ION  are  a term.  The  I-machine  cannot  run  if  “ION. 

finally,  predicates  1,  2,  20,  and  21  are  locally 

inter ference-free. 


Safe  access  is  considered  in  the  following  table: 


Var iable 

SCHR 

RPID 

Best 

REDO 

P.BW 

P.link 


Access  Reason  for  Safety 
R/w  Atomic  access 

R/W  SCHR«true  forbids  other  accessors 
R/W  Process  local  variable 

R/W  Atomic  access 

R Atomic  access 

R Read-only  access,  all  accessors 


The  inner  loop  terminates  because  of  the  finite  and 
unchanging  length  of  the  process  list.  The  outer  loop  does 
not  necessarily  terminate.  This  is  not  an  error,  however, 
for  if  there  is  a ready  process,  the  loop  can  terminate.  If 
no  interrupt  programs  execute  I WAKE  while  the  loop  is 
running,  it  will  terminate.  If  interrupt  programs 
continually  wake  P-machine  processes,  the  loop  won’t 
terminate. 
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Freeze-k  k k<100  {FREEZE} 


Freeze-k+1 


Proof 


1 {Freeze-k  t Freeze<100) 


Freeze  : - Freeze+1 


2 { Preeze-k+1  fc  Freeze<-1001 


Comments 

Predicate 

Freeze-0 

FreezeOO 

Var iable 
Freeze 


Reason  for  interference-free 
See  beginning  of  section  8.5 
See  beginning  of  section  8.5 

Reason  for  safe  access 
Atomic  access 


THAW 

Specification 


Freeze-0 


{THAW} 


Proof 


1 {Freeze-0} 


if  Freeze>0  then  Freeze  ;-  Freeze-1; 

if  Freeze-0  and  RSCH-true  then  CS  fi 
fi 


2 {Freeze-0} 

Comments 

Predicate 

Freeze-0 


Variable 

Freeze 


Reason  for  interference-free 
See  beginning  of  section  8.5 

Reason  for  safe  access 
Atomic  access 
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Specification 


Freeze-1 


{THAW}  Freeze-0 


with  oneof 


{THAW}  RPID-T  a PSEL(T)  a "RSCH 


Proof 


1  {Freeze*!  a PIV21 


if  Freeze>0  then 


2  {Freeze-1  a PIV2} 


3  {Freeze-0  a PIV21 


4  {Freeze-0} 


Freeze  Freeze-lj 


if  Freeze-0  and  RSCH-true  then 


5  {Freeze-0  a ION)  end  of  proof  for  this  path. 


6 {Freeze-0  a PIV2} 


7 {Freeze-0  a PIV2) 


Comments 


Predicate 
Fr eeze<>0 
Freeze-1  a PTV2 


Reason  for  interference-free 
See  beginning  of  section  8.S 
Freeze-1  is  locally  interference-free 
and  PIV2  is  invariant,  hence  locally 
inter  ference-f ree. 

Locally  interference-free 


Variable 

Freeze 

RSCH 


Reason  for  safe  access 
Atomic  access 
Atomic  access 
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Specification 

P7  Preeze-k  4 k>l  (THAW)  Freeze-k-1 

Proof 

1 {Freeze-k  k k > 1 1 

if  Preexe>0  then 

2 {Freeze-k  k k > 1 > 

Freeze  :-  Freeze-1; 

3 {Freeze-k-1  & FreezeX)) 

if  Freeze-0  and  RSCH-true  then  CS  fi 
fi 

4 {Preeze-k-1} 

Conunenta 

See  P6  comments 

BLOCK  (P) 

Specification 

P8  QORPID  {BLOCK  Q}  ION 

with  oneof 

P8a  Q.st-B  I Q.st-R  {BLOCK  Q}  Q.st-B 

P8b  Q.st-RW  {BLOCK  Q}  Q.st-R 

Proof 

1 {QORPID  & Freeze-k} 

FREEZE;  DI 

2 {QORPID  k Freeze-k+1  & 'ION) 


■ 
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if  P.KW'true  then 

3 {'P.BW  k P.WW)  P.WW:-false  {'P.BW  k 'P.WW) 

else  if  P.BW-faise  then 

4 {'P.BW  k “P.WW)  P. BW:-true  fi  {P.BW  k *P.WW} 
f i 

El 

5 {QORPID  k Freeze-k+1  k ION) 

if  RPID-Q  then  Freeze  :»  0;  CS 
else 

6 {QORPID  k Freeze-k  + 1 k ION) 

THAW 

7 {QORPID  & Freeze-k  k ION) 

f i 

0 {QORPID  k Freeze-k  & ION) 


Comments 

Predicate 

FreezeOO 

Freeze-k 

ION 

‘ION 

3,  4 


Var iable 
P.WW,  P.BW 
RPID 


Specification 


Reason  for  inter ference- free 
See  beginning  of  section  8.5 
See  beginning  of  section  8.5 
See  beginning  of  section  8.5 
See  beginning  of  section  6.5 
"ION  k Freeze>0  so  full  exclusion 
allows  sequential  proof. 

Reason  for  safe  access 

All  context  switching  disabled 

Freeze>0  prevents  any  write  access 


P9 


Q-RPID 
with  oneof 


{BLOCK  Q) 


Freez^-0  & ION 


H 


- 
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P9a  Q.st-B  I Q.st-R  {BLOCK  Q)  Q.st*B  & RPID-T  f.  PSEL(T) 

P9b  Q.st-RW  {BLOCK  Q}  Q.st*R  & RPID=T  i PSEL(T) 


Proof 


{Q-RPID  & Freeze*k) 

PREEZE;  DI 

{ Q*RPID  & Freeze»k+1  & ‘ION} 

if  P.WW*true  then  P.WW  false 

else  if  P.BW=false  then  P.BW  :J 
f i 

El 

{Q»RPID  & Freeze=k+1  & ION} 
if  RPI D=P  then 
{ Q=»RPID  & Freeze  = k + 1 & ION} 

Freeze  :=  0; 

{Q*RPID  & Freeze=0  & ION} 

CS 

{Freeze=0  & ION}  end  of  this  path 

else  THAW 
f i 


true  fi 


Comments 


See  P9,  above. 


WAKE  (P) 

Specification 

P10  Fr eeze=0  {WAKE  Q}  ION 

with  oneof 

PlOa  Q. St=R  | Q. st=RW  {WAKE  Q}  Q.St=RW 


Proof 

1 {Freeze-0  & PIV2) 

FREEZE;  DI 

2 {Freeze-1  & PIV2  & "ION) 

if  Q.BW-true  then 

3 {Q.BW  fi.  -Q.WW)  Q.BW  false  {‘Q.BW  i.  ~Q.WW) 

else  if  Q.WW-false  then 

4 {-Q.BW  & -Q.WW)  Q.WW  true  {“Q.BW  fi.  Q.WW) 

fi 

fi 

El 


5 {Freeze-1  & 

ION  fi. 

-RSCH  ->  (V  ROQ:  R.pri  > RPID.pri  ->  R.BW)  1 
if  Q.pr i>RPID.pr i then 

6 {Freeze-1  fi.  ION  s.  Q.pr i>RPID. pr i ) 

• RSCH  true 

7 {Freeze-1  & ION  & PIV2) 


8  {Freeze-1  & ION  fi.  PIV2] 
THAW 


9  {Freeze-0  fi.  ION) 


Comments 


Predicate 
Fr eeze-k 
PIV2 

‘RSCH  •> 

(V  ROQ:  R.pri 
ION 


Reason  for  inter ference -free 
See~Eegrnning  of  section  8.5 
invariant,  so  interference-free 
Same  argument  as  PIV2 
> RPID.pri  ->  R.BW' 

See  beginning  of  section  8.5 


j 
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'ION 
3,  4 


See  beginning  of  section  8.5 
'ION  6 Freeze>0  bo  full  exclusion 
allows  sequential  proof. 


Variable 
Q.WW,  Q.BW 
RPID 

RPID.pr i 


Reason  for  safe  access 
All  context  switching  disabled 
Freeze>0  prevents  any  write  access 
Atomic  access  (given  safe  access  to  RPID) 


Specif icat ion 


Pll 

FreezeOO  {WAKE  Q) 

ION  & 'RSCH  -> 

(RPID-T  i PSEL(T) ) 

with  oneof 

Plla 

pllb 

Q.st-R  I Q.st-RW  {WAKE  Q) 

Q. St*B  {WAKE  Q) 

Q.  st-RW 

Q.  st-R 

Proof 

1 {Freeze-k  6 k > 0 } 


FREEZE;  DI 

2 {Freeze-k+1  & k>0  S.  ~IONl 

if  Q.BW-true  then 

3 {Q.BW  (.  'Q.WW]  Q.BW  false  {'Q.BW  & "Q.WW) 
else  if  Q.WW“false  then 

4 {'Q.BW  6 'Q.WW)  Q.WW  :■  true  {'Q.BW  & Q.WW) 
fi 

fi 

El 

5 {Freeze-k+1  & k>0  & ION  & 

( ~RSCH  ->  (V  ROQ:  R. pr  i>RPID . pr  i->R . BW)  ) ) 

if  Q.pr i>RPID.pr i then 

6 {Freeze*k+1  fc  k>0  t>  ION  & 

Q.pr  i>RPID.pr  i t> 

'Q.BW  } 


RSCH  true 
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7 (Preeie-k  + 1 k k>0  k ION  i. 

( 'RSCH  »>  (V  Ri  R.pr i>RPID.Dr i ■>  R.BW))  I 

fi 

8 |Free*e»ktl  k k>0  k ION  k 

( * RSCH  ■>  (V  Ri  R.pr i>RPID.pi i •>  R.BW))  ) 

THAW 

9 (Freexe-k  fc  k>0  *-  ION  (■  PIV2) 


Comment* 

Predicate  Reason  for  interference-free 

Preeie«f  ’ 5ee~EegInnlng  o7  section  ST? 

PIV2  invariant,  ao  interference-free 

*RSCH  •>  Same  argument  as  PIV2 

(V  ROQj  R.pri  > RPID.pri  •>  R.BW) 

XON  See  beginning  of  section  8.5 

-jON  See  beginning  of  section  8.5 

3 4 'ION  k Free«e>0  ao  full  exclusion 

allows  sequential  proof. 

*Q.BW  Fr eexe>0  ao  no  P-machine  program  can 

change  Q.BW,  and  there  are  no  I-machine 
operations  that  can  set  Q.BW«true. 

Vat  table 
07««T'5:bw 

RPID 
RPIO. pr 1 


Reason  for  safe  access 
KTT  context  switching  disabled 
Preeze>0  prevents  any  write  access 
Atomic  access  (given  safe  access 
to  RPID) 


IWAKE  |Pj 

Sped  f icat  ion 

11  Preexe>0  k (IWAKE  Q) 

RPIDOni  1 k 
Q.pr i^RPlD.pr i 

with  oneof 


Ua  Q.at-R  I Q.at-RW  (IWAKE  Q) 

lib  Q.st-B  (IWAKE  Q) 


Q.at-RW  k JO.ev 
Q.at-R  k JO.ev 


Proof  of  the  Kernel 


8-30 


12  Freeze-0  & { IWAKE  Q) 

RPIDOnil  & 

Q.pr i<-RPID.pri 

with  oneof 

I2a  Q.st-R  I Q.st-RW  {IWAKE  Q}  Q.st-RW 

I2b  Q.st-B  {IWAKE  Q}  Q.st-R 

13  FreezeOO  6 {IWAKE  Q]  RSCH 

RPIDOnil 

with  oneof 

I3a  Q.st-R  I Q.st-RW  {IWAKE  Q}  Q.st-RW 

I3b  Q. st=B  {IWAKE  Q}  Q.st-R 

14  RPID-nil  {IWAKE  Q)  REDO 

with  oneof 

I4a  Q.st-R  I Q.st-RW  {IWAKE  Q}  Q.st-RW 

I4b  Q.st-B  {IWAKE  Q)  Q.st-R 

The  proof  of  the  first  few  statements  is  common  to  all  parts. 

Proof 

1 {ION '-ION} 

IONSave  :=  ION 

2 { IONSave-ION 1 } 

DI 

3 { IONSave-ION'  & "ION  } 

if  Q.BW-true  then 

4 { Q.  BW  & ~Q.WW}  Q.BW  :=  false  {“Q.BW  S>  ~Q.WW} 
else  if  Q.WW-false  then 

5 {"Q.BW  & -Q.WW}  Q.WW  :=  true  {"Q.BW  & Q.WW} 
fi 

fi 


6  { IONSave-ION'  & "ION  } 
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lf  lONSave-true  then 

7 { ION' “true  4 "ION  1 

8 { ION-ION1  ) 


El  fi 


If  SCHR-true  then 

9 { SCHR  ) case  14 

REDO  j • true 

10  { SCHR  4 REDO  ) end  of  case  14 

else  if  Kreete<>0  then 

11  { "SCHR  4 freeieOO  ) case  I) 

RSCH i-t r ue 

12  { "SCHR  4 Freezes >0  4 RSCH  1 end  case  II 

else 

13  { "SCHR  4 Freeze-0  } 

if  Q. pr i >RP I D. pr i then 

14  { "SCHR  4 Freeze-0  4 Q. pr i >RPID. pr i I case  II 

ARMINT 

15  { JO.ev  ) end  case  II 

f i 
f i 
f i 


Comments 


Predicate 

Freeze-0 

FreezeOO 

ION 

"ION 

IONSave 

4,  5 


Reason  for  interference-free 
Wr iter  is  lower  priority 
Writer  is  lower  priority 
See  beginning  of  section  8.5 
See  beginning  of  section  8.5 
Exclusive  access  to  IONSave 
"ION  so  full  exclusion 


! 
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SCHR , -SCHR 

allows  sequential  proof. 

Writer  is  lower  priority 

REDO 

Processes  that  can  set  REDO*false  are 

RSCH 

lower  priority 

Processes  that  can  set  RSCH*false  are 

Q. pr i >RPID. pr i 

lower  priority 

Processes  that  affects  these  variables 

JO.ev 

are  lower  priority 

Process  that  can  set  JO.ev*false  is 

lower  priority 


Variable 

Reason  for  safe  access 

Q.WW,  Q.BW 

All  context  switching  disabled 

SCHR 

Atomic  access 

RSCH 

Atomic  access 

REDO 

Atomic  access 

IONSave 

Exclusive  access 

RPID 

Writer  is  lower  priority 

RPID.pr i 

Atomic  access  (given  safe  access  to  RPID) 

Q.pr  i 

Atomic  access 

Specification 

15  IPID-JO  {RETICS} 


with  oneof 


1 5a 


Preeze-0  & 
(forall  KOJ0: 
K. st-idle) 


{RETICS}  IPID=nil  & JO.st-idle  & 

AM-'P'  & RPID-T  & PSEL(T) 
& "RSCH  & ‘REDO  & ION 


Proof 

1 {Freeze«0} 

CS 

2 {ION} 

The  oneof  predicates  are  taken  care  of  by  the  execution  of 
CS  and  the  Z-80A  hardware. 


, 


I 


* 
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8.6  - Verification  of  Theorems 

Theorem  L If  * BLOCK  P is  executed,  P will  not  run  until  a 
WAKE  P (or  I WAKE  P)  is  executed. 

Proof 

Suppose  the  first  oneof  axiom  (P8a  or  P9a)  applies.  Then 
P. st*B  and  P cannot  run  because  PSEL(P)  cannot  be  true  as  it 

must  (Pla)  for  P to  continue  execution.  The  only 

transitions  that  can  change  P.st-B  are  PlOb,  Pllb,  lib,  I2b, 
I3b,  and  I4b.  Each  of  these  is  a WAKE  or  IWAKE  operation. 

In  the  case  of  the  second  oneof  axiom  (P8b  and  P9b) , the 
pre-condition  P.st»RW  implies  that  a WAKE  P or  IWAKE  P has 

already  been  executed  as  WAKE  and  IWAKE  are  the  only 

operations  that  have  P.st-RW  as  post-conditions. 

Theorem  2^  If  no  WAKE  P or  IWAKE  P operations  are  executed, 
a process  P will  not  run  after  at  most  2 BLOCK  P operations 
are  executed. 
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Proof 

Suppose  P.st-RW.  Then  after  one  execution  of  BLOCK  P, 
P.st-R  (P8b,  P9b) . BLOCK,  WAKE,  and  IWAKE  are  the  only 
operations  affecting  P.st  and,  by  hypothesis,  WAKE  and  IWAKE 
are  not  executed.  In  this  case,  or  if  P.st-R  already,  an 
execution  of  BLOCK  P results  in  P.st-B  (P8a,  P9a) . P cannot 
run  when  P.st-B.  Thus,  at  most  2 executions  of  BLOCK  P with 
none  of  WAKE  P results  in  P.st-B. 


Theorem  3 . A P-machine  context  switch  will  not  be  performed 
unless  Freeze-0. 

Proof 


Follows  directly  from  Pi  and  15  as  Freeze-0  is  a 
pre-condition  for  both  of  these  operations  and  no  other 
operations  cause  context  switching  on  the  P-machine. 


This  completes  the  verification  of  the  Kernel. 
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examined  to  establish  some  property  of  a part  of  it  is 
minimized. 

Abstraction  and  virtual  machines  also  simplify  the 
specification  task.  The  individual  abstractions  and  virtual 
machines  can  be  specified  individually.  Additional,  more 
global,  specifications  relate  them. 

The  idea  of  virtual  machines  and  interrupt  disabling  has 
been  combined  in  a new  technique  for  mutual  exclusion.  If 
context  switching  among  a group  of  processes  is  disabled, 
then  the  one  of  them  that  is  running  has  exclusive  access  to 
all  its  variables.  None  of  the  other  processes  can 
interfere  until  context  switching  is  again  enabled. 

Real-time  responsiveness  can  be  maintained  by  establishing  a 
separate  virtual  machine  on  which  all  but  interrupt  programs 
run.  When  context  switching  is  disabled  on  this  virtual 
machine,  interrupt  servicing  is  unaffected.  Mutual 
exclusion  among  all  non-interrupt  processes  is  achieved. 

This  technique  is  easy  to  implement,  requires  no  queues  or 
other  complex  data  structures,  and  has  positive  effect  on 
the  verification  task.  When  context  switching  is  disabled, 
only  a single  process  can  execute  so  that  sequential 
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for  use  by  other  processes.  Predicates  used  in  the 
verification  of  basic  computations  will  not  change  if  the 
basic  computation  is  a region  that  excludes  from  execution 
all  processes  that  can  affect  variables  in  any  of  the 
predicates.  This  condition  covers  the  cases  where  there  are 
no  other  processes  that  can  affect  variables  as  well  as  the 
case  where  context  switching  is  disabled  so  that  no  other 
processes  can  run. 

Priority  based  scheduling  can  provide  an  environment  that 
assures  that  certain  variables  will  be  unchanged  during  the 
execution  of  a basic  computation.  If  all  processes  that 
read  (but  not  write)  the  particular  variables  are  of  higher 
priority  than  processes  that  modify  the  variables,  then  any 
actions  based  on  examination  of  such  shared  variables  in  the 
same  basic  computation  cannot  be  affected  by  processes  that 
modify  the  variables.  This  situation  occurs  when  interrupt 
programs  examine  variables  describing  the  state  of  the 
system  that  are  set  by  normal,  lower  priority,  processes. 

Conditions  that  assure  that  variables  that  can  be  accessed 
atomically  (set  and  loaded  properly)  were  also  examined. 
Sufficient  conditions  include  true  (machine  dependent) 
atomic  access,  exclusion  among  accessors,  access  by  only  a 
single  process,  and  read-only  access  by  all  processes. 
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Next  the  algorithms  were  shown  to  be  consistent  with  the 
specifications.  This  involved  both  a derivation  similar  to 
conventional  axiomatic  proofs  and  arguments  that  the 
predicates  used  are  not  modified  by  any  other  processes. 
The  theorems  were  proved  by  considering  possible  actions 
performed  by  some  of  the  operations  that  could  not  be 
carried  in  predicates  because  of  interference  from  other 
processes . 

9.2  - Value  of  Verification  Analysis 

This  thesis  claims  to  address  the  practical  aspects  of 
operating  system  design  and  verification;  some  comments  on 
the  value  and  difficulty  of  the  task  is  in  order.  As  noted 
in  the  introduction,  program  correctness  is  important  but 
only  one  of  several  valuable  program  properties.  We 
conclude,  however,  that  structuring  that  contributes  to 
engineering  aspects  of  a program  is  not  in  conflict  with 
structure  that  aids  verification.  The  practical  value  of 
good  engineering  properties  are  clear  in  reducing  cost  and 
increasing  reliability  and  applicability  of  a program. 


The  practicality  of  performing  an  extensive  verification  is 
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questionable.  We  do,  however,  claim  that  some  of  the 
analysis  that  underlies  the  proof  is  valuable  and  practical. 
Many  of  the  complex  problems  that  appear  in  real-time 
systems  are  related  to  variable  access  or  modification  in  an 
unexpected  state.  In  the  course  of  the  verification  of  the 
Kernel,  one  error  of  this  nature  was  uncovered. 

The  criteria  given  for  safe  variable  access  can  be  applied 
to  all  variables  in  the  program  in  a fairly  mechanical  way. 
Potential  trouble  spots  can  thus  be  identified.  The 
analysis  required  for  proving  the  soundness  property  of 
basic  computations  is  also  valuable  in  identifying  potential 
trouble  spots  in  a system.  The  analysis  identifies  what  is 
assumed  by  various  computations  in  the  program  and  where  in 
the  program  those  can  be  affected.  It  is  likely  that  these 
analyses  would  uncover  most  serious  and  subtle  errors  in  a 
system.  This  type  of  error  is  also  unlikely  to  be  revealed 
in  testing  as  subtle  issues  of  timing  and  sequencing  may  be 
involved.  The  training  required  to  analyse  programs  for 
these  problems  is  also  not  extensive. 

9.3  - Difficulty  of  Specifications 

The  development  of  the  specifications  was  of  similar 
complexity  to  the  proof  itself.  This  is  partially  due  to 
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the  continual  refinements  that  were  required  as  the 
specification  techniques  themselves  were  refined. 
Experience  has  been  beneficial  in  making  the  specification 
production  easier. 

Still,  the  complexity  and  difficulty  of  finding  an 
appropriate  model  and  axiomatizing  the  operations  is  not  to 
be  underestimated.  Analysis  of  what  variables  will  be 
consistently  accessable  is  not  an  issue  in  the 
specifications,  but  identification  of  those  usable  in 
predicates  in  proofs  is. 

Subtle  errors  in  the  specifications  of  the  P and  I-machine 
operations  were  found  at  a uniform  rate  even  as  the  thesis 
approached  completion.  There  is  no  reason  to  believe  that 
no  errors  remain;  nor  is  there  any  obvious  way  to  get  to 
such  a conviction. 

9.4  - Further  Research 

There  are  many  directions  for  further  research. 

- Much  of  the  technique  exposed  in  this  thesis  is  left 
informal.  More  formal  and  perhaps  mechanical 
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techniques  can  be  developed. 

- It  seems  likely  that  the  detection  of  unsafe  access 
to  variables  can  be  done  mechanically.  What 
properties  of  a language  are  required  to  do  this? 

- Why  are  specifications  so  hard  to  write?  How  can 
they  be  produced  more  easily?  (Additional  experience 
might  help.) 

Can  a weakest-precondition  like  calculus  can  be 
defined  that  expresses  the  soundness  property  of 
basic  computations  in  terms  of  the  structure  of  the 
language  in  which  the  program  is  written? 

What  other  criteria  are  there  for  safety  and 
soundness?  Can  they  be  mechanically  checkable? 

- Can  the  notion  of  binding  be  formalized?  Would  a 
measure  of  it  help  in  evaluating  quality  of  software 
and  language  design? 

- How  can  time  be  added  to  specifications? 
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